邮件客户端过滤CSS是安全策略而非兼容性问题：Gmail移除flex/grid/@media等样式，Outlook因Word引擎中断style解析，Apple Mail启用CSS白名单；必须用table布局、内联白名单样式、vertical-align:top兜底。
CSS 在邮件客户端里不是“兼容性差”，而是被主动过滤——你写的样式大概率根本没进渲染流程。
为什么 Gmail/Outlook/Apple Mail 会“吃掉”你的 CSS
这不是浏览器兼容问题，是邮件服务商的硬性安全策略：
- Gmail 服务端会扫描并移除所有
display: grid、display: flex、@media、!important（部分版本除外）、background-image等声明 - Outlook Desktop（基于 MS Word 引擎）遇到
display: grid会直接中断整个<style>块解析，后续样式全丢 - Apple Mail 启用 CSS 白名单机制：
grid-template-columns、gap、minmax()全部静默剔除 -
<head>和<style>标签在绝大多数客户端中被直接剥离，class属性也被忽略
哪些“兼容写法”其实毫无意义
很多开发者试图靠语法降级绕过限制，但这些在邮件场景中完全无效：
-
@supports (display: grid)：所有主流邮件客户端都不识别该语法，整块规则被清除 -
display: -ms-grid或grid: 'autoplace'：IE 专有前缀，而 IE 已退出历史；Outlook 不认，Gmail 直接过滤 -
style="display: grid"写成内联：Gmail Android/iOS、Outlook iOS/macOS 仍会校验值并删除非法display -
display: contents模拟结构：Outlook 完全忽略该声明，子元素塌陷，布局全乱
真正能落地的三件事
邮件开发没有渐进增强，只有强制回归。能活下来的只有这三条路径：
立即学习“前端免费学习笔记（深入）”；
- 用
<table>构建所有布局结构：列靠嵌套<td>，行靠<tr>，宽度用width="600"+style="width: 600px;"双保险 - 所有样式必须内联，且只用白名单属性：
color、font-family、font-size、padding（margin基本失效）、text-align、vertical-align: top（<td>必写，否则 Outlook 默认居中挤变形） - 字体栈末尾加兜底：
font-family: Helvetica, Arial, sans-serif；单位只用px或百分比，禁用rem/em
自动化内联不能跳过校验环节
用 CssToInlineStyles（PHP）或 juice（Node.js）转内联只是起点，之后必须人工验证：
-
juice.inlineContent(html, css, { preserveImportant: true })是基础配置，但preserveImportant必须开——Outlook 某些版本只认带!important的关键样式 - 转换后检查是否残留
class或未处理的<style>：Outlook 会直接忽略含class的整行标签 - 每个
<td>必须显式带style="vertical-align: top;"，哪怕父级已设；<table>自身尽量不用style，改用 HTML 属性控制 - 响应式不能靠
@media：Gmail Web / Apple Mail 支持width: 100%+display: block切换，但 Outlook 完全无视，只能靠多套表格结构+条件注释模拟
最常被忽略的点是：本地浏览器预览正常 ≠ 邮件可用。Chrome 能渲染 grid，不代表 Gmail Web 会用 Chrome 渲染你的邮件——它用的是自己定制的服务端 HTML 清洗器。
