邮件预览功能实现：EML解析与HTML安全过滤全指南

后台管理系统但凡涉及邮件模块，基本都会遇到一个高频需求：邮件预览功能。无论是客服工单里需要查看往来的邮件记录，运营后台要给营销邮件做发前检查，还是测试人员想快速验证一封邮件在不同客户端的渲染效果，邮件预览都是绕不开的环节。我最近刚把一个前端邮件预览功能从零完整落地，翻车和踩坑的次数比预想的多不少，其中涉及最多的就是解析EML文件、处理编码乱码、隔离HTML注入风险这几件事。这篇文章把我的完整实现过程、方案取舍和出过的故障整理出来，给准备做同样功能的同学一条可以直接抄的路线。

这个功能本身解决的核心矛盾是：前端拿到一封邮件的原始内容（大多数情况下是EML格式文件或邮件服务返回的结构化JSON），需要在网页里尽可能还原邮件原本的排版和视觉效果，同时保证页面安全、不出现乱码、附件能正常下载、内联图片能正常显示。适合的产品场景很固定：客服工单系统、邮件营销平台、企业协同办公应用、以及各类需要展示邮件内容的CMS后台。对技术栈的要求不高，核心语言是JavaScript，但涉及编码处理、MIME结构理解、HTML安全过滤几个相对冷门的知识点，需要提前做好准备。

1. 整体设计思路与方案取舍

1.1 需求场景与常见实现形态

在动手之前，先搞清楚产品要的“邮件预览”具体是哪种形态，不同形态的实现复杂度差别非常大。我梳理了一下，市面上常见的形态大概有三类。

第一类是纯前端展示，数据源是后端已经解析好的JSON结构，包含邮件的发件人、收件人、主题、正文HTML、附件列表、发送时间等字段。前端只需要把JSON渲染到页面上，把正文部分用iframe或div嵌入即可。这是最轻量的方案，基本没有解析负担，适合大多数内部管理系统。

第二类是前端直接拉取EML文件并在浏览器端完成解析。EML是邮件客户端导出和邮件服务商存储的标准格式，本质上是遵循RFC 822和MIME规范的文本文件。自主解析EML能绕开后端解析服务，但要求前端处理base64、quoted-printable、多种字符集、嵌套MIME结构，代码量和工作量都会显著上升。

第三类是混合方案，后端做粗糙解析把邮件内容和附件拆开，前端做精细渲染。我最终落地的就是这种方案，原因后面会说。

1.2 方案选型的核心权衡逻辑

我一开始的想法是纯前端解析，因为这样后端只需要提供一个EML文件下载地址，逻辑上最干净。后来推翻这个方案主要有三个原因。

第一个原因是安全。邮件HTML是外部输入，里面可以内嵌恶意脚本、钓鱼链接、跟踪像素。如果在前端直接解析并把整段HTML用 dangerouslySetInnerHTML 塞进页面，相当于给攻击者开了一扇门。如果解析和HTML净化都在Node端做，可以用成熟的邮件解析库加白名单过滤器，处理得更彻底，同时不暴露给浏览器端。

第二个原因是编码兼容性。邮件的字符集五花八门，UTF-8、GBK、GB2312、ISO-8859-1都有可能出现。Node端处理Buffer和字符集转换非常自然，借助相关库能覆盖绝大多数编码组合。浏览器端的 TextDecoder 虽然也能处理一部分，但碰到带编码声明的老邮件、或是在Content-Type里缺失charset参数的情况，容易解码失败。

第三个原因是性能。一份带大附件的EML可能有几十MB，直接丢给浏览器解析会造成主线程卡顿、内存暴涨。Node端解析时可以跳过附件原始内容，只提取元信息，把网络传输体积降到十分之一以下。

所以最终的架构是后端Node服务负责EML解析、附件提取、HTML白名单过滤和图片代理，前端负责接收解析结果并渲染。这条链路的好处是职责清晰、安全可控、性能有保障。

1.3 完整数据链路设计

整个邮件预览功能的数据流可以拆成一条直线：邮件服务商投递到系统邮箱 → 系统存储原始EML文件 → Node解析服务读取EML并生成结构化JSON → 前端调用预览接口获取JSON → 前端渲染页面并加载附件和内联图片。

JSON的核心字段我设计成下面这个样子：

{ "messageId": "<...>", "subject": "本周项目周报", "from": { "name": "张三", "address": "[e-mail]" }, "to": [{ "name": "李四", "address": "[e-mail]" }], "cc": [], "date": "2024-11-05T10:00:00.000Z", "html": "<div>净化后的HTML</div>", "text": "纯文本内容", "attachments": [ { "filename": "周报.xlsx", "mimeType": "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet", "size": 102400, "contentId": "[e-mail]", "downloadUrl": "/api/mail/attachment/123" } ], "inlineImages": [ { "contentId": "[e-mail]", "viewUrl": "/api/mail/inline/123" } ] }

前端拿到这个JSON，渲染就变得非常省事。主题、收发件人走普通DOM绑定，正文直接用iframe承载html字段，附件列表单独渲染。整个链路上的关键节点都在后续章节里展开。

2. EML文件格式解析与核心原理

2.1 EML到底是个什么东西

EML文件本质上是一个纯文本文件，遵循RFC 822和MIME标准。一个标准EML文件长这样：

Received: from mail.xxx.com (unknown [192.168.1.1]) Date: Mon, 04 Nov 2024 14:30:00 +0800 From: =?UTF-8?B?5byg5LiJ?= <[e-mail]> To: [e-mail] Subject: =?UTF-8?B?5pyo5pyo5oKf5pel?= Message-ID: <[e-mail]> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_12345_67890" ------=_Part_12345_67890 Content-Type: multipart/alternative; boundary="----=_Part_99999_00000" ------=_Part_99999_00000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 5pyo5pyo5oKf5pel5rWL6K+V ------=_Part_99999_00000 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHk+PHA+5pyo5pyo5oKf5pel5rWL6K+VPC9wPjwvYm9keT48L2h0bWw+ ------=_Part_99999_00000-- ------=_Part_12345_67890 Content-Type: application/octet-stream; name="report.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="report.pdf" JVBERi0xLjQK... ------=_Part_12345_67890--

从这段示例能直观看到，一封EML文件分为信封头部和正文两大部分。信封头部（headers）在第一个空行之前，包含From、To、Subject、Date、Message-ID、Content-Type等元信息。正文部分如果包含多个子内容，则是multipart结构，通过boundary分隔符划分各区块，每个区块本身又可以有自己独立的头部和编码方式。

要正确解析EML，核心就是递归处理这棵树：根节点是multipart/mixed，下面可能嵌套multipart/alternative（同内容的纯文本版和HTML版）、multipart/related（HTML正文和其中的内联图片）、以及单独的附件节点。解析程序要做的就是把树遍历一遍，把叶子节点中的内容解码出来，区分出HTML正文、纯文本正文、附件和内联图片。

2.2 邮件头部编码规则与解码逻辑

邮件头部中的From、To、Subject等字段，如果包含非ASCII字符，会使用RFC 2047编码，即常说的Encoded-Word。它的格式是：

=?字符集?编码方式?编码内容?=

比如=?UTF-8?B?5byg5LiJ?=表示用UTF-8字符集、base64编码方式、内容经解码后是“张三”。编码方式有两种，B表示base64，Q表示quoted-printable。Q编码中可打印的ASCII字符直接显示，非ASCII字符用十六进制加下划线表示，例如=E5=BC=A0代表一个UTF-8编码的汉字。

这里有个很常见的坑：开发者在解码邮件头时，容易忽略解码后可能还包含空格、换行、以及多个Encoded-Word相邻拼接的情况。RFC 2047允许一个长字段被拆成多个编码段，中间用空白和换行分隔。如果你只取第一个编码段去解码，会把主题截断。正确的做法是先按折叠空白把头部字段里的软换行拼接起来，再正则匹配出所有=?...?=...=?..?=结构，逐段解码后拼接。

2.3 邮件正文的Content-Transfer-Encoding处理

正文区块的编码处理相对直接。Content-Transfer-Encoding字段指示用什么方式传输，常见值有 base64、quoted-printable、7bit、8bit。

base64编码是好处理的，每4个字符代表3个字节，直接在Node端用 Buffer.from(encodedText, 'base64') 解码即可。quoted-printable则需要把=后跟两个十六进制字符的形式还原成对应字节，处理时要小心=出现在行尾的情况，那表示软换行，应该直接剔除。

对于7bit和8bit，理论上内容本身就是可打印ASCII或扩展ASCII，直接当字符串处理就行。但从稳定性角度，我始终把解码结果存为Buffer对象，再根据Content-Type里声明的charset转成文本。这是因为邮件正文声明了UTF-8但实际上夹杂GBK字节的情况真实存在，仅靠字符串操作容易乱码。

2.4 解析代码骨架

如果不想在Node端用现成的解析库，自己写一个精简解析器也完全可行。核心代码结构如下：

const { TextDecoder } = require('util'); // 解析头部字段 function decodeHeader(rawHeader) { // 先处理折叠行，再逐字段按 Encoded-Word 解码 return rawHeader.replace(/=\?([^?]+)\?([bBqQ])\?([^?]*)\?=/g, (match, charset, encoding, content) => { const buf = encoding.toLowerCase() === 'b' ? Buffer.from(content, 'base64') : Buffer.from(content.replace(/=/g, '=').replace(/_[_]/g, ' '), 'binary'); try { return new TextDecoder(charset.replace('gb2312', 'gbk')).decode(buf); } catch (e) { return content; } }); } // 递归解析MIME树 function parseMimeNode(node) { const contentType = node.headers['content-type'] || 'text/plain'; if (contentType.startsWith('multipart/')) { // 按 boundary 切分内容，递归解析每个子节点 } else if (contentType.startsWith('text/')) { // 解码文本内容，存为 text/html 或 text/plain } else { // 附件节点，提取 filename、content-id、attachment 标志 } }

自己写解析器的优点是完全可控，能按项目需求裁剪逻辑，缺点是需要自己处理各种边界情况，比如boundary前后多了空格、Content-Type参数大小写不固定、嵌套深度异常等。我更推荐的是在Node端直接用开源库，用现成方案做边界兜底，然后对产出结果再做一层二次加工。

3. 解析库选型与后端服务搭建

3.1 邮件解析库的横向对比

Node生态里解析邮件的库，常用的主要是三个。我逐个试过一轮，简单说一下各自的特性。

第一个是mailparser。这是Node生态里应用最广泛的邮件解析库，支持EML文件和原始RFC 822字符串输入，内部处理了大部分MIME边界情况，能输出结构清晰的JSON。它的优点是文档全、社区活跃、处理附件和内联图片有现成API。缺点是它对邮件头里的Encoded-Word解码偶尔会遗漏极少数复杂组合，需要自己补一轮。

第二个是postal-mime。这个库的体积更小，也能直接解析EML，但它对附件和内联图片的区分、以及对畸形邮件的容错，比mailparser要弱一些。适合做简单场景，不适合作为主解析器。

第三个是mime-message，它更侧重生成邮件而非解析邮件，做预览功能用不上，只提一句。

我最终选了mailparser作为解析底座，因为它能把纯文本正文、HTML正文、附件列表、内联图片列表全部结构化输出，国际化和中文兼容都经历过大量生产环境验证。关键的坑在于mailparser默认会把内联图片也放进attachments数组，所以后面必须自己做一轮二次处理，把有contentId标记的提取出来单独归类。

3.2 后端解析服务的接口设计

解析服务我封装成一个独立的模块，核心是输入EML原始Buffer，输出前端可用的JSON。对外暴露两个接口：一个是按邮件ID获取解析结果，另一个是按附件ID获取附件二进制流。

邮件ID路由的设计是这样的：邮件存储时每条记录有唯一ID，解析服务根据ID找到存储路径，读取EML文件，解析并缓存结果。缓存很重要，因为同一封邮件可能被不同用户预览多次，每次重新解析大附件会影响性能。我会把解析后的JSON缓存到内存或Redis里，附件二进制流则不缓存，直接走存储系统读取。

接口返回的数据结构，就是第一章列出的那个JSON。需要注意的一点是，html字段只保存净化后的内容，不能直接拿原始解析结果里的html塞进接口响应，这一步净化必须放在服务端完成。

3.3 HTML净化与防注入

邮件HTML是外部输入，净化是必须做的。我采用的策略是服务端白名单过滤，不允许任何标签和事件属性默认通过。具体做法是把HTML先按标签级联过滤，只保留p、div、span、a、img、table、tr、td、ul、ol、li、br、h1到h6、strong、em、blockquote、hr这些常规排版标签；再去掉除src、href、alt、title、width、height、align、border、cellpadding、cellspacing之外的所有属性；最后对a标签的href做协议白名单检查，只允许http、https、mailto三种协议。

这里有个经验：不要试图用黑名单过滤危险内容，黑名单永远赶不上攻击者的变形技巧。白名单过滤虽然会丢失一部分复杂的邮件排版样式，但安全性是实打实的。

对于内联样式style属性，策略取决于产品需求。如果产品追求高还原度，可以放行style属性并使用CSS属性值白名单校验，只允许color、background-color、font-size、text-align、font-family等非危险属性。如果产品对安全更敏感，干脆全部移除。我采用的是折中方案：过滤style内属性，保留排版必需项，去掉position、z-index、behavior、expression等高风险内容。

4. 前端渲染层实现细节

4.1 用iframe承载HTML正文

前端渲染邮件正文，我是直接用iframe的srcdoc属性来承载净化后的HTML。选iframe而不是div并用innerHTML插入，是因为iframe有天然的隔离性，邮件内的CSS作用域不会跑出去影响主页面样式，同时主页面样式也不会干扰邮件排版。

渲染代码很简洁：

const frame = document.getElementById('mail-preview-frame'); frame.srcdoc = ` <html> <head> <meta charset="utf-8" /> <style>body { font-family: Arial, sans-serif; margin: 16px; }</style> </head> <body>${mailData.html}</body> </html> `;

但srcdoc有一个明显的坑：它受同源策略限制，iframe内部不能直接访问父页面的数据。如果想在邮件HTML里加载内联图片或附件，必须通过绝对URL。所以我在前端拿到解析结果后，会把img标签里相对路径的src替换为带签名或带token的完整URL。

4.2 相对路径转绝对地址

邮件正文里的图片src可能值非常多样，有的是完整URL，有的是相对路径 /images/xxx.png，有的是CID引用 cid:[e-mail]，还有的是data URI。我在前端统一做一次地址规范化处理。

处理逻辑如下：后端解析结果里已经内置了附件和内联图片的访问URL，前端拿到后建立一个map，key是contentId，value是downloadUrl。然后遍历HTML DOM中所有img标签，按src属性取前几位判断：以cid:开头的，替换成map里对应的viewUrl；以/开头的相对路径，拼接上邮件系统的静态资源前缀；其他情况原样保留。

这一步还要处理一个边缘情况：如果邮件HTML里的src是编码过的非ASCII字符串，比如URL中包含中文文件名，需要先用decodeURIComponent解码再判断，否则匹配不上内联图片的contentId。

4.3 邮件高度的自适应计算

预览iframe高度调成多少是个麻烦问题。固定高度会导致长邮件出现滚动条，用户体验差；高度自适应又需要跨origin访问iframe内容。

我用的方案是在iframe onload之后，通过contentWindow.document.body.scrollHeight拿到内容高度，再动态设置iframe高度。但这个操作的前提是同源。如果邮件资源部署在CDN或独立域名，srcdoc加载的内容仍然算同源，因为srcdoc文档的origin是继承父页面的，所以这个方案可以直接用。

代码大致如下：

frame.addEventListener('load', () => { try { const height = frame.contentDocument.body.scrollHeight; frame.style.height = height + 'px'; } catch (e) { frame.style.height = '600px'; } });

如果遇到跨域情况拿不到高度，就退化为设置一个较大默认值，交给iframe内部滚动，不强行追求自适应。

4.4 外链图片与隐私保护处理

邮件HTML中可能包含外链图片，这些图片往往是发件人的追踪像素，用于判断收件人是否打开了邮件。预览功能如果直接加载这些外链图片，会在展示邮件的同时泄露出预览者的IP和时间信息，甚至可能暴露内部网络环境。

我做的策略是：默认拦截所有外链图片，DOM渲染时把所有跨域img请求代理到后端，由后端统一发起请求并缓存结果。这样前端浏览器不会直接与第三方域名发生连接，有效切断了追踪链路。代价是图片加载延迟会增加，但换来的隐私保护在企业管理场景下是值得的。

代理接口是 /api/mail/image-proxy?url=encodeURIComponent(外部地址)。后端收到请求后会做域名白名单校验，非白名单域名一律返回占位图。这一步和HTML净化一样，都必须放在服务端做，绝不能信任前端传来的url参数。

5. 附件与内联图片的完整处理方案

5.1 附件提取与下载接口

解析库mailparser会把所有非文本内容统一放到attachments数组，每项包含filename、content、contentType、contentId、related字段。related为true表示该附件是内联图片，false才是真正的独立附件。我在后端做二次处理时，把related为true的节点移到inlineImages数组，剩下的才保留在attachments里。

附件下载接口的注意点主要是两块。第一块是文件名编码，Content-Disposition头里的filename如果包含中文，必须做RFC 5987编码，用 filename*=UTF-8'' 配合encodeURIComponent处理，否则浏览器下载中文附件名会乱码。第二块是下载响应头，Content-Type要用实际MIME类型而不是application/octet-stream，否则部分附件无法被浏览器直接预览，比如PDF会变成下载而不是在线打开。

5.2 内联图片的CID映射

内联图片是邮件正文中通过img标签引用的资源，它不通过URL访问，而是通过CID引用。EML文件中IMG标签的src是 cid:[e-mail]，对应MIME结构里Content-ID为 [e-mail] 的附件节点。

后端处理内联图片时，要建立一个从contentId到访问地址的映射表并输出到JSON中。前端拿到JSON后，把邮件HTML中所有 cid: 开头的src替换为对应的viewUrl。这个映射关系如果漏了某一条，邮件里就会出现破图。排查时我习惯先把解析结果里所有的contentId打印出来，与HTML中出现的cid做一遍差集比对，能够快速定位缺失项。

5.3 附件预览与加载策略

附件列表的展示，我用了简洁的卡片样式，显示文件名、大小和下载按钮。大附件下载时会有进度反馈，这个用XMLHttpRequest的progress事件实现，前端直接拿fetch拿不到精确进度。另一个细节是附件预览，支持常见可预览格式（PDF、图片、纯文本）在浏览器新标签页打开，Excel和Word这类二进制格式直接触发下载，不强行用第三方组件解析，避免引入大量复杂度。

对于超大附件，还有一个优化点：如果附件超过10MB且不是内联图片，在JSON解析时只提取元信息，不把二进制数据放进响应体。下载时单独发起接口请求。这样列表页加载速度不会受单封超大邮件拖累。

6. 乱码问题与兼容性实战记录

6.1 中文乱码出现的根源

邮件预览绕不开乱码这个话题。乱码的本质是编码和解码采用了不同字符集。我遇到过一个很典型的案例：一封从某老版本邮件客户端发出的EML，头部里写着Content-Type: text/plain; charset="gb2312"，但正文实际是GBK编码的字节流。用gb2312解码大部分中文能正常显示，但极少数生僻字和特殊符号会出错。所以我在统一转换文本时，遇到gb2312一律按gbk处理，排除了这个坑。

另一个容易踩的坑是UTF-8的BOM遗留。有些邮件附件和正文开头带BOM标记，解码后字符串最前面出现不可见字符，在界面里表现为一个小方块或缩进异常。解码后要统一做stripBOM处理。

6.2 历史邮件的编码兼容策略

老邮件常在Content-Type里不声明charset，或声明的charset与实际不符。针对这种邮件，我采用的是启发式回退机制：优先级从高到低为Content-Type声明 > 头部字段编码 > 内容byte流的前几个字节特征 > 系统默认UTF-8。

具体做法是，用Node的TextDecoder逐个尝试候选字符集，并统计解码结果的替换字符占比。占比越低说明该候选集越可能是真实编码。这里有个注意点：GBK解码几乎任何字节序列都能成功，所以候选字符集顺序很重要，必须在尝试GBK之前优先尝试UTF-8（无替换字符=合法UTF-8），再尝试GBK作为回退。

6.3 邮件客户端兼容性清单

这个功能上线后，通常会遇到各种主流邮件客户端的渲染差异。Outlook对HTML邮件的支持就是典型的另类要求，它依赖Word引擎渲染，对CSS的margin和padding支持有严重问题，常见表现是原来的样式在Outlook里变乱。Thunderbird和Apple Mail对标准HTML的兼容性最好，基本能像素级还原。网页邮箱则主要看内核，Chrome内核下表现比较稳定。

面对这些差异，我能做的不是逐客户端适配，而是在解析服务里提供一份兼容性优化策略：对HTML做一次规范化转换，把table布局相关的属性补齐，padding改用table的cellpadding、cellspacing表达，减少对复杂CSS的依赖。这一轮转换能解决掉80%以上的排版错乱问题。

6.4 编写解析结果自测用例

这里强烈建议，功能上线前建立一套覆盖多场景的测试邮件样本集，至少包括纯文本邮件、带HTML排版邮件、带内联图片邮件、带中文附件邮件、嵌套multipart的复杂邮件、跨多个字符集的历史邮件。每一封样本邮件都要有对应的预期解析结果快照，作为回归测试的基础。

这套样本集在后续迭代中价值极大。每处理完一个新的解析Bug，就往样本集里补一封引起该Bug的邮件，确保同样的故障不会二次引入。

7. 常见问题与排查技巧实录

7.1 高频故障速查表

把我在开发过程中遇到过的典型故障整理成了一张速查表，方便团队内部排障时直接查阅。

现象	可能原因	排查方向与解法
预览页面一片空白	邮件本身只有纯文本，无HTML部分	检查解析结果是否含html字段，没有则降级使用text字段并包裹在pre标签中展示
HTML中图片全部破图	CID映射缺失或viewUrl拼接错误	打印contentId列表，与HTML中的cid引用做差集比对
中文主题显示为问号	header解码未处理Encoded-Word	检查Subject字段解析流程，确认RFC 2047解码已生效
中文附件下载乱码	Content-Disposition未按RFC 5987编码	下载接口响应头改为 filename*=UTF-8'' 形式
iframe高度异常	邮件HTML结构缺失或高度计算过早执行	在load事件后判断contentDocument可用性再取scrollHeight
邮件正文被主页面样式污染	正文直接用div渲染而非iframe隔离	改用iframe的srcdoc承载邮件HTML
很长的邮件导致页面卡顿	前端渲染超大HTML	限制单封渲染的HTML长度，超出部分折叠并提示用户
预览页面加载慢	外链图片大量请求阻塞	走图片代理并启用缓存，缩短响应等待时间

7.2 断点调试技巧

邮件解析这类过程复杂的功能，调试时最实用的方法是把每一步中间产物都打印出来。解析结果JSON、净化前后的HTML对比、CID映射表、编码转换前后的Buffer内容，这几个关键节点必须能看到日志或辅助调试入口。

我在调试时习惯给解析服务加一个debug参数，传了之后接口响应里额外返回原始EML的前2000字符和解码后的头部原始字段。前端再配合一个调试面板，直接查看这个中间产物，定位问题能节省大量时间。

7.3 一个典型的“乱码”排查案例

有一次相关同事反馈某封邮件预览时中文全部变成乱码，我定位了一轮才发现问题不在解码环节，而是在存储环节。邮件服务商把EML文件写入存储时用的字符集是UTF-8，但编码过程中丢失了部分非ASCII字节的高位，导致原始EML本身损坏。解码环节再怎么正确也无法还原已损坏的数据。

这个问题最后是靠推动存储链路改造解决的：在邮件服务商侧增加EML原始数据的完整性校验，并在存储时做一次UTF-8合法性和字节序列占比检查，不合格的邮件单独标记并进入人工复核队列。这提醒我，邮件预览这类功能排查思路要往上游看，不只是看解析代码本身。

8. 一些值得沉淀的实操体会

邮件预览功能做完之后，回过头再看整个过程，有一个认识非常深刻：这个功能真正的难点不在渲染，而在解析链路对异常输入的宽容度。真实生产环境里的EML文件，格式之混乱远超RFC标准文档的描述。有些邮件工具导出的EML文件在参数之间混用空格和Tab，有些在boundary前后多加了一行破折号，有些在头部字段里塞了裸换行。优秀的解析方案不是把所有情况都预判到，而是处理不了的时候优雅降级——展示纯文本、隐藏异常附件、或者给用户一个格式提示，都比直接报错要好。

另一个值得提的经验是安全边界的划分。我在最终架构里坚持把HTML净化和外链图片代理放在服务端，前端只做内容展示，这个决定在此后的安全评审里被反复验证是合理的。前端不管做多少层过滤，攻击者都可以绕过前端直接请求接口、篡改DOM。只要服务端守住净化这道防线，预览功能就在安全的范围内。

最后的最后，提一个日常开发容易忽略的小细节。写邮件预览功能时，建议在页面里保留一个“查看原始邮件”的入口。这个入口不是给普通用户用的，而是给开发和客服排障用的。点击后展示EML原始文本或一份未净化的解析快照，再配合浏览器开发者工具的响应查看能力，可以极大提升复现和定位问题的效率。这个功能虽然不起眼，但实际使用频率非常高。