很多 HTML 邮件在浏览器预览里很整齐，发到 Outlook 后却出现间距消失、两栏错位、卡片变直角、按钮不像按钮等问题。它通常不会让邮件彻底报错，而是悄悄把信息层级弄乱。
解决方法不是背一张无穷长的兼容表，而是先判断：这条 CSS 是承担“让收件人看懂”的基础结构，还是只负责锦上添花的视觉效果？
打开免费的 EasyAImail Email HTML Preflight，粘贴或上传最终 HTML，即可在浏览器中查看检查报告。
为什么 Outlook 要单独检查
Outlook 并不是一个完全统一的渲染环境。Outlook Classic、新版 Outlook、网页版 Outlook 与浏览器预览的行为都可能不同。因此“在 Chrome 里没问题”并不能说明邮件在客户的 Outlook 里也没有问题。
上图中的检查结果把 Outlook 相关风险单独列出来，包括 gap、display:flex、max-width、margin、padding、背景色、圆角和阴影等。它们的严重程度并不相同：阴影没了通常只是美观变化；如果两栏布局、关键间距或按钮区域失效，就可能让收件人看不清重点。
先区分基础版式和渐进增强
基础版式，是收件人无论使用什么客户端都应获得的信息：标题、正文、关键日期、主要操作、可点击的链接，以及合理的阅读顺序。
渐进增强，是有更好当然不错、失效也不该影响理解的效果：柔和阴影、渐变、较大的圆角、精细的响应式排版等。
如果某条 CSS 只负责渐进增强，经过人工确认后可以接受它在一部分客户端失效；如果它控制的是内容顺序、可读性、对比度或主要操作，就该在发送前改成更稳妥的写法。
几类最值得重点看的 CSS
Flex 和 Grid
网页布局习惯使用 display:flex 或 grid 来分栏、对齐和分配间距。邮件里，如果两栏关系、阅读顺序或主要操作依赖它，使用更稳妥的 table 结构作为基础通常更可靠。
这并不代表所有邮件都要回到复杂表格。关键是不要让一个兼容性较弱的布局方式独自承担“内容必须怎么排”的责任。
gap、margin 和 padding
间距一旦只是为了好看，问题不大；但当它是标题与正文、两个操作按钮或提示信息之间唯一的分隔时，就会影响理解。检查器会标出这类风险，提醒你把关键间距放在更稳定的结构上，例如对应的表格单元格。
max-width
max-width 能让浏览器预览更精致，但部分邮件客户端可能不按预期处理。对于必须保持可读宽度的主体内容，应采用在不同宽度下仍有意义的结构，而不是只依赖浏览器里的理想尺寸。
圆角、阴影和背景
border-radius、box-shadow 大多属于渐进增强。可以保留，但按钮和卡片不应该只靠阴影或圆角才显得可点击、可区分。背景同样如此：如果去掉 body 背景后文字和按钮就失去对比度，说明基础结构还不够稳。
一个更兼容的基础写法
当网页版组件依赖 flex、gap、阴影和圆角时，不要逐项硬搬进邮件。先把它承担的任务翻译成可靠的邮件结构。
项目进度更新
修改后的文件已准备好，请您查看。
它未必像网页组件那么“轻巧”，但可以先保护信息层级。基础结构稳定后，再考虑加回不会影响阅读的视觉效果。
把报告当成排查清单，而不是自动改写器
EasyAImail Email HTML Preflight 提供“渐进增强”和“严格兼容”两种检查思路。渐进增强适合先保证邮件在不同客户端都有可读的基础版本，再把 Head 中的视觉差异视为较低优先级；严格兼容则更适合需要进一步压缩客户端差异的场景。
无论选哪一种，都不应该把每条提示当成同一种错误。打开安全预览，查看被标出的内容区域，再问自己：即使这条样式失效，收件人能否仍然读懂、找到下一步并正常点击？
静态检查不能替代真实收件箱测试
检查器不会把邮件发送到每个 Outlook 版本、操作系统和个人设置中，因此不能承诺像素级一致，也不预测送达率。它的价值是把容易忽略的风险提前摆出来，让你在真实测试前知道最该看哪里。
对于涉及重要订单、账户、截止时间或大规模触达的邮件，建议先跑检查，再把最终版本发送到你真正关心的邮箱客户端中测试。
别漏掉内容本身的风险
一封邮件即使在 Outlook 里排版还可以，也可能因为缺少 alt 文本、按钮仍指向 #、变量没有替换而失效。检查器会把这些内容和无障碍问题放在同一份报告里，避免你只盯着 CSS 而忘了收件人实际会看到什么。
想进一步了解浏览器预览与收件箱之间的差异，可以阅读为什么邮件在 Outlook 里排版全乱：从浏览器到收件箱的差异。
常见问题
新版 Outlook 和 Outlook Classic 支持的 CSS 一样吗？
不要假设一样。把它们看作不同目标环境，优先保证基础版式，而不是只在一个预览里追求完美。
被标出的 CSS 都要删掉吗？
不需要。先修复会影响内容顺序、对比度、主要操作和可读性的项目。阴影或圆角等装饰性差异，在基础可读性没有问题时可以作为渐进增强保留。
HTML 邮件能用 flex 吗？
可以把现代 CSS 作为增强，但不应让核心内容顺序和关键信息间距完全依赖它，尤其是在 Outlook 收件人较多时。
浏览器预览正常，能说明 Outlook 也没问题吗？
不能。浏览器预览能检查你的预期版式，但 Outlook 有不同的渲染行为。重要邮件应结合静态报告和真实收件箱测试。
先修复承担信息的那部分
把最终 HTML 放进 EasyAImail Email HTML Preflight，优先处理影响结构、间距、操作和对比度的风险。装饰效果可以后置，但收件人必须先读得懂邮件。
