Cerberus

Cerberus：用三头犬守住 HTML 邮件的三道门

项目背景与痛点

做过 HTML 邮件的人都知道一个残酷的事实：这不是前端开发，而是跨渲染引擎的兼容性考古。同一个 div，在 Chrome 里是块级盒子，在 Outlook 2016+ 里会被 Word 的排版引擎拆得七零八落；max-width 在 Outlook 桌面版基本等于不存在；Gmail 长期剥离 <style> 块的部分能力，只保留属性选择器；而 iOS Mail 又几乎是个完整的 WebKit。

于是社区演化出两套路线：一套是 MJML、Foundation for Emails 这类编译型 DSL，用抽象语法生成表格汤；另一套是 emailmonday/Cerberus 代表的模式集路线——不给你框架，只给你几套经过实战验证的、可以直接抄走改的模板骨架（单列、双列、三列、Hero 图、邮件签名等）。

Cerberus 解决的核心问题不是"如何写邮件"，而是"如何在没有任何构建工具的前提下，写出一个在 Outlook、Gmail、Apple Mail 三处都不崩的响应式骨架"。它的名字取自神话里的三头犬，恰好对应这三道门：一个头盯 MSO（Microsoft Outlook 的 Word 渲染引擎），一个头盯 Gmail 的样式裁剪，一个头盯移动端的流体缩放。

核心技术揭秘

Cerberus 的真正价值在于它把三种互相冲突的约束，用三个互不依赖的层叠加了起来。

第一层是结构层：全量 table 嵌套，配合 role="presentation" 声明语义中立。所有间距用 padding 而非 margin 控制（Outlook 对 margin 支持极差），所有图片强制 display:block; border:0，消灭行内图片下的幽灵间隙。

第二层是布局层，也就是常说的 fluid hybrid / “spongy” 技巧。外层 <table width="100%"> 撑满视口，内层内容容器只用 max-width: 600px；对不认识 max-width 的 Outlook，用 MSO 条件注释塞一个宽度固定的 ghost table 作为外壳：

<!--[if mso]><table role="presentation" width="600" align="center"><tr><td><![endif]-->
  <table role="presentation" width="100%" style="max-width:600px;"> ... </table>
<!--[if mso]></td></tr></table><![endif]-->

这样同一份 DOM 在 MSO 下是固定 600px 的刚性布局，在其他客户端则是随窗口流动的弹性布局。

第三层是增强层：<head> 里的媒体查询只做渐进式改造——把多列 td 从 inline-block 掰成 display:block; width:100% 的单列堆叠、放大触控目标、压缩标题字号。关键选择器刻意使用 [class~="mobile-stack"] 这种属性选择器写法，正是为了照顾 Gmail 的 CSS 白名单。

这套设计的数据流本质上是单向降级：结构层永远成立，布局层在支持的客户端上生效，增强层只锦上添花。任何一层失效，邮件都不会变成乱码，最多是"少一点优化"。这是它区别于许多"能跑但脆"的模板的关键判断。

功能亮点与差异

杀手锏是"零工具链"。Cerberus 没有 npm install、没有编译步骤、没有专有标签。克隆下来用浏览器打开预览页，改文案就能上线。对于一套一年只改两次的事务型邮件（订单确认、密码重置、发票通知），这种低认知负担远比 MJML 的工程化更有吸引力。

第二个差异是"模式化而非框架化"。它提供的是 6～8 个独立可组合的 pattern，每个 pattern 都能单独抽出来用，不会像框架那样把整封邮件绑架到自己的抽象里。你完全可以把 Cerberus 的双列卡片塞进一个自研的模板体系。

第三个隐性优势是体积。结构精简意味着源码通常只有十几 KB，远离 Gmail 那个"超过 102KB 就被折叠"的剪裁阈值——而重度的组件化框架生成的表格汤很容易踩线。

代价也很明确：它没有变量、没有循环、没有组件复用。你需要自己接 Handlebars、Nunjucks 或后端模板引擎，把 pattern 变成可参数化的产物。

应用场景与落地建议

适合：事务型通知邮件、SaaS 产品邮件、 newsletters 的骨架起点。不适合：需要数十个可变模块、多语言多品牌、频繁 A/B 测试的营销邮件体系——那种规模应当直接上 MJML。

生产落地有几条硬建议：

1. 内联 + 保留 head。用 juice 或 premailer 把关键样式内联，但务必保留 <style> 块中的媒体查询，别被内联工具清空。
2. 图片走绝对 URL 的 CDN，并显式写 width 属性（Outlook 不认百分比时会塌陷），同时确保 retina 双倍图降采样。
3. 不要把 600px 当作普适真理。如果你的正文有宽表格或数据报表，考虑 700～800px 断点，并在窄屏上改为卡片化堆叠。
4. 必测矩阵：Outlook 桌面（Windows）、Outlook.com、Gmail Web/App、Apple Mail、iOS 深色模式。至少在 Litmus 或 Email on Acid 上跑一轮，Cerberus 只保证骨架，不保证你的内容。
5. 深色模式要单独兜底。模板本身只提供基础 prefers-color-scheme 处理，透明 PNG 和纯白背景在深色模式下大概率翻车。

综合评价

优点：极简、可读、无构建依赖；对 Outlook 的处理干净利落，ghost table 方案是业界标杆写法；代码本身就是最好的教学材料，读一遍胜过十篇兼容性博客；体积小，规避 Gmail 剪裁风险。

缺点：本质是模板集合而非工程方案，无组件化、无参数化，规模化后会陷入复制粘贴的泥潭；客户端行为持续演进（尤其 Gmail 近年的 [data-ogsc]、暗色模式、剪裁策略），这类"手工维护的兼容性"需要你持续跟踪，而编译型方案只需升级依赖。

一句话：如果你一年只发几封邮件，Cerberus 是最省心的起点；如果你需要一条邮件产线，用它做参考实现，然后迁移到 MJML。