邮件客户端遇到不支持的CSS属性时的行为：与浏览器是否存在差异？

嘿，先明确第一个问题的答案：这个说法是正确的。当Chrome、Firefox这类主流浏览器碰到不认识的CSS属性时，会直接跳过该属性，完全不影响其他有效CSS规则的解析和渲染——简单说就是“无效属性单独忽略，有效规则正常生效”。

但邮件客户端的行为就没这么统一了，和浏览器存在不少关键差异，主要有这些注意点：

• 兼容性碎片化远超浏览器：不同邮件客户端的CSS支持度天差地别，甚至同一品牌的不同版本差异都很大。比如Windows桌面版Outlook用的是Word的渲染引擎，对border-radius、flexbox这类现代CSS特性支持极差；Gmail会过滤掉大部分外部样式表，只认内联样式；Apple Mail则相对接近浏览器的支持程度。这种碎片化导致它们处理不支持属性的逻辑完全不统一。
• 部分客户端会忽略整个规则块：不像浏览器只跳过单个无效属性，有些邮件客户端（比如Windows桌面版Outlook）如果检测到规则里有它不支持的属性，可能会直接忽略整个选择器对应的所有样式。举个例子：

  .email-text {
    color: #333;
    border-radius: 4px; /* Outlook桌面版不支持 */
    font-size: 14px;
  }
  

  在Chrome里会显示深灰色14px文字+圆角，但Outlook桌面版可能连color和font-size都不生效，直接用默认样式。
• 内联样式的特殊处理：浏览器里内联样式、内部样式、外部样式的优先级规则清晰，但邮件客户端大多对外部/内部样式支持有限（比如Gmail几乎完全不支持外部样式），所以通常需要把样式内联到元素上。即便如此，有些客户端还是会忽略内联里的某些属性——比如Outlook会忽略内联的margin属性，得用表格布局来模拟间距。
• 存在各种“怪癖”行为：比如有些客户端会把不支持的属性视为语法错误，导致后续属性也被忽略；还有些客户端会对某些属性做“自定义降级”，比如把不支持的box-shadow转换成笨拙的边框模拟，结果和预期效果大相径庭。

总的来说，邮件客户端的CSS处理逻辑比浏览器复杂得多，不能直接套用浏览器的“忽略单个无效属性”的经验，做邮件开发时必须针对主流客户端做兼容性测试，尽量使用邮件客户端普遍支持的基础CSS特性。

内容的提问来源于stack exchange，提问作者Limbo