一封 HTML 营销邮件已经设计完成，测试发送到 Gmail 后，却发现后半部分被藏进了“查看完整邮件”链接。这不只是一个视觉问题：页脚、退订信息或追踪元素都可能被截断。同一份 HTML 里还可能同时存在暗黑模式、Outlook、图片、字体和无障碍问题，只靠肉眼查看源码很难一次发现。
HtmlDrag 的邮件兼容性修复器为这类场景提供了一条浏览器本地预检流程。你可以上传 `.html` 文件或粘贴源码，先预览邮件，再扫描兼容性风险，选择需要应用的修复，最后下载修复后的 HTML，或者继续进入可视化编辑器调整内容和样式。
本次演示使用的示例邮件故意包含以下问题：
- 冗余 HTML 让文件体积超过 Gmail 约 102KB 的剪裁预警线。
- 图片缺少 ALT 属性。
- 自定义字体没有通用字体回退。
- 深色文字和浅色容器在暗黑模式下存在显示风险。
- 圆角 CTA 和表格细节需要考虑 Outlook 渲染差异。
- 移动端、自动链接、对比度和语义无障碍风险。
这条流程的目标不是自动重做整封邮件，而是在保留可见结构的前提下消除可避免的交付风险。完成技术修复后，如果文案、品牌颜色或布局还需要人工判断，可以继续进入可视化编辑器完成最后调整。
Gmail 剪裁 HTML 邮件意味着什么
当邮件 HTML 体积过大时，Gmail 可能截断消息，把剩余内容放到“查看完整邮件”链接后面。通常讨论的阈值大约是 102KB，但最终结果也会受到实际投递内容影响。重复的行内样式、构建器元数据、重复区块、大量空白和注释，都可能增加源码体积，却不会给收件人增加任何可见价值。
把文件压到预警线以下很重要，但体积只是邮件质量检查的一部分。即使 Gmail 不再剪裁，邮件仍可能出现暗黑模式文字不可读、图片没有说明、字体回退不完整，或者 Outlook 中按钮和表格表现不同。因此，这次流程不是只看一个数字，而是先做一次更完整的邮件兼容性扫描。
完整流程：检测、修复、预览并继续编辑
步骤 1：上传 HTML 邮件或直接粘贴代码
打开邮件兼容性修复器。左侧可以直接粘贴 HTML，右侧可以上传 `.html` 或 `.htm` 文件。本次演示上传的是一封故意放大源码体积的营销邮件。在这个阶段，兼容性分析和所选修复都在浏览器本地执行，修复器不会为检测而上传或存储邮件 HTML。
如果邮件来自其他邮件构建器或旧模板库，上传文件通常最直接；如果你手上已经是一段 HTML 代码，粘贴源码可以省掉中间文件。
步骤 2：修改前先预览原始邮件
文件通过检查后，HtmlDrag 会在预览区域渲染邮件。这是应用任何自动修复前的重要视觉检查点：你可以确认标题、CTA、内容卡片和页脚是否完整，并切换明亮或暗黑预览，观察明显的颜色与对比度问题。
页面同时保留两个后续入口：使用“智能修复”扫描兼容性问题，或直接进入 HTML 编辑器手动调整。本次示例的源码体积过大，而且包含多种非视觉风险，所以先执行扫描。
步骤 3：查看检测结果，而不是盲目重写整封邮件
点击智能修复后，系统会分析当前 HTML，并返回一个可选择的检查清单，而不是直接重写所有内容。截图中共识别出 16 项可处理问题，最醒目的包括高风险 Gmail 剪裁、图片缺少 ALT，以及字体缺少回退。
每一项都会说明风险和拟执行的操作。例如 Gmail 剪裁对应 HTML 压缩；缺少 ALT 的图片会补充安全回退值；不完整的字体栈会增加通用字体。其他检查还可能覆盖 Outlook、viewport、暗黑模式、自动链接样式、语义标题和文本对比度。
步骤 4：只应用你确认需要的修复
保留需要处理的项目，然后点击立即应用修复。HtmlDrag 会重新解析文档，注入选中的兼容补丁，更新可安全处理的属性；当选中 Gmail 剪裁修复时，还会压缩 HTML。处理期间会显示进度和当前阶段。
这种选择式处理对生产邮件更稳妥。你可以先阅读清单，排除与有意设计冲突的项目，并把原始文件保留为回退版本，而不是让工具在没有确认的情况下改写全部内容。
步骤 5：确认兼容性修复已经完成
处理结束后，成功窗口会确认已经应用所选暗黑模式补丁、Outlook 兼容优化和代码压缩。这代表本轮处理顺利完成，但不等于所有邮件客户端都会完全一致。正式发送前，仍建议在目标用户常用的客户端中做真实测试。
步骤 6：预览修复结果并下载 HTML
关闭结果窗口后，会回到修复后的邮件预览。此时页面除了“智能修复”和“编辑 HTML”，还会出现下载入口。再次检查可见结构，切换明亮和暗黑模式，并在下载前对比原始版本和修复结果。
本次示例的大部分额外体积来自不可见的冗余内容，所以压缩后尺寸下降明显。真实邮件的情况会有所不同，不应假设所有超大邮件都能减少同样比例；正确做法是查看最终文件体积并做投递测试。
步骤 7：进入可视化 HTML 编辑器继续处理
兼容性修复和内容编辑是两类不同任务。技术处理完成后，点击编辑 HTML，即可把修复后的邮件带入 HtmlDrag 可视化编辑器。画布保留完整邮件，右侧则提供文字、组件、图层和样式控制。
如果扫描后发现某个区块虽然技术上有效，但 CTA 仍不清楚、文案太长、对比度不够或层级需要优化，就可以在这里继续处理，不必回到源码里寻找对应标签。
步骤 8：交付前完成最后的视觉调整
最后一张截图选中了三列卖点区，并直接调整文字色和背景色。这里展示了自动兼容性修复与人工设计控制之间的分工：智能修复负责重复性的技术补丁，可视化编辑器负责需要品牌判断的颜色、文案和布局。
最终调整完成后，可以按照平时的 HtmlDrag 工作流保存版本或导出 HTML。如果从本地修复器继续进入保存、分享或其他账号功能，后续操作会遵循对应的正常产品流程，与浏览器本地兼容性分析是两个阶段。
一次兼容性检查可以处理哪些问题
| 风险 | 为什么重要 | 典型处理方式 |
| Gmail 剪裁 | 体积过大的 HTML 可能被藏到“查看完整邮件”后面 | 压缩 HTML，移除冗余源码体积 |
| 缺少 ALT 属性 | 图片被屏蔽或使用读屏软件时会缺少上下文 | 先添加安全回退，再为信息型图片补充有意义的说明 |
| 暗黑模式对比度 | 硬编码颜色在反色后可能变得难以阅读 | 注入受支持的配色声明和对比度补丁 |
| Outlook 渲染 | 圆角按钮、背景和表格间距可能出现差异 | 应用 Outlook 兼容回退和表格补丁 |
| 无障碍与移动端元数据 | 语义不足或 viewport 缺失会影响使用体验 | 补充可安全处理的属性，再到编辑器复核文案 |
发送前的实用检查清单
- 所有活动内容和追踪代码加入后，再检查最终 HTML 体积。
- 分别预览明亮和暗黑显示效果。
- 逐项阅读检测结果，不要无差别接受所有修改。
- 对有信息价值的图片，用有意义的描述替换空 ALT 回退。
- 把修复结果带入可视化编辑器，完成文案和品牌样式调整。
- 在目标用户常用的 Gmail 和 Outlook 版本中进行真实测试发送。
常见问题
Gmail 一定会在正好 102KB 时截断邮件吗？
通常引用的限制大约是投递后 HTML 的 102KB，但邮件平台加入追踪代码或重写链接后，Gmail 实际收到的内容可能与本地源文件不同。因此，应把预警当作发送前的风险信号，并用真实收件箱测试最终活动邮件。
智能修复会重新设计整封邮件吗？
不会。兼容性处理集中在你选中的技术风险，例如代码压缩、元数据、字体与图片回退、暗黑模式支持和无障碍属性。需要主动调整文案、颜色、间距或布局时，再进入可视化编辑器处理。
运行兼容性检查时会上传邮件吗？
本流程展示的兼容性分析和修复在浏览器本地执行，不会为了修复而上传或存储邮件 HTML。如果之后主动使用账号保存、分享或其他流程，则会遵循对应功能原本的数据处理方式。
应用修复后还需要发送测试邮件吗？
需要。不同邮件客户端使用不同渲染引擎，发送平台也可能在投递期间修改源码。可以把修复器作为预检步骤，但最终仍应在目标用户常用的客户端和设备中检查真实投递结果。
总结
Gmail 剪裁往往只是 HTML 邮件需要更完整预检的第一个可见信号。识别冗余源码体积的同一次扫描，还可以发现缺少 ALT、字体回退薄弱、Outlook 风险、暗黑模式对比度，以及移动端和无障碍缺口。
HtmlDrag 把这些技术检查接入后续编辑闭环：上传或粘贴邮件、查看检测结果、在浏览器本地选择修复、预览处理后的版本，然后下载 HTML，或者继续进行有明确目的的可视化调整。