software

与网页不同的世界：电子邮件模板工作中的试错

发布: (2026年1月2日 GMT+8 13:19)
7 min read
原文: Wanted Tech

Source: Wanted Tech

网页与其他世界：邮件模板工作中的踩坑经历

在 Wanted，我们会发送通知求职完成、材料通过等招聘进程以及合格/不合格结果的邮件。这些邮件长期使用同一套模板，最近我们开始对这些邮件模板进行一次全新改版。

本文将以一名前端开发者的视角，分享在制作邮件模板时遇到的问题、原因以及解决方案。希望对首次接触邮件模板的朋友们能提供一点参考资料。

问题场景

新改版的邮件模板是 在网页和移动网页上以响应式方式展示的设计。在工作开始前，我收到几份之前使用的邮件模板 HTML，发现其中通过 CSS 媒体查询实现了响应式处理。因此，我也参考了旧模板，采用媒体查询来实现响应式设计进行开发。

问题场景 1：移动端未触发响应式

将实现好的模板应用后发送测试邮件，在移动端查看时发现原本期待的响应式布局根本没有生效。尤其是想通过媒体查询调节图片尺寸的部分完全没有被应用，导致图片在移动端被放得过大，整体布局被破坏。

此时我开始怀疑 邮件环境下常规的网页响应式做法可能并不适用。

问题场景 2：相同的移动环境下呈现各异

在遇到第一问题后，我放弃了响应式设计，改为 在网页和移动端保持相同布局，只根据屏幕尺寸自然缩放比例。再次发送测试邮件后，移动端确实以缩放后的比例展示。

但即使在同样的移动环境下，不同的客户端仍呈现出细微差别：

  • 移动 Safari 浏览器
  • Gmail 应用
  • Naver 邮件应用
  • iOS 原生邮件应用

进一步检查后发现，之前使用的邮件模板在不同客户端也会出现类似的布局差异。

原因：邮件客户端不是浏览器

问题的根本原因其实很简单。邮件客户端并不是网页浏览器。

网页浏览器的特性

  • 使用标准 HTML / CSS 渲染引擎
  • 几乎完整支持 flex、grid、media query、box model 等

邮件客户端的现实

邮件客户端各自使用 不同的内部渲染引擎。

  • Outlook（Windows） → 使用 MS Word 渲染引擎
  • Gmail（网页 / 应用） → CSS 过滤 + 自己的解析器
  • iOS Mail → 基于 WebKit（相对正常）
  • Naver / Kakao 邮件 → 限制性的 WebView

也就是说，假设 CSS 能像在浏览器中那样被准确渲染的前提根本不成立。

邮件中 CSS 失效的原因

1. <style> 标签与选择器支持受限

  • 复杂的 CSS 会被忽略或只部分生效
  • class 选择器、后代选择器等会被过滤
  • 在 Gmail 网页/应用中尤为常见

2. display 属性支持不完整

  • display: flex;、display: grid;、display: inline-block; 等
  • Outlook：几乎全部被忽略
  • Gmail：仅部分支持，例外很多

3. Box model 不稳定

  • margin: auto;、padding: 16px; 等
  • Gmail：正常
  • Outlook：margin 被忽略，padding 失效
  • 移动端应用：视环境而定，表现随机

4. 与层叠/遮罩相关的属性基本无效

  • z-index、overflow: hidden 等
  • position 失效导致这些属性也失效
  • 类似横幅上文字覆盖的结构几乎不可能实现

5. 响应式 / 媒体查询不稳定

  • @media 支持差异极大
    • Gmail 网页/应用：❌
    • Outlook：❌
    • iOS Mail / Apple Mail：✅

👉 如果用媒体查询来实现“移动端适配”，只有部分 iOS 客户端能正常显示，其他大多数会直接展示桌面版。于是出现 不同邮件客户端只会部分应用 CSS 的局面。

解决方案：table 布局 + 行内样式

为什么选 table？

table

  • 从 HTML 3.x 时代就存在
  • 在 CSS 出现之前就被用于布局
  • 是邮件客户端绝对不能破坏的核心标签

从邮件客户端厂商的角度来看，“div、flex、grid 失效可以接受，但 table 失效会导致大量邮件崩溃”，于是 只有 table 能得到最可靠的支持。

邮件中最实用的布局模式

<table width="600" align="center" cellpadding="0" cellspacing="0" border="0">
  <tr>
    <td>
      <!-- 内容 -->
    </td>
  </tr>
</table>

这种结构的优势

  • ✅ 桌面端：600 px 固定宽度布局
  • ✅ 移动端：屏幕变窄时自然缩小
  • ✅ 无需媒体查询也能实现类响应式效果
  • ✅ 包括 Outlook 在内的绝大多数邮件客户端表现一致

这并不是基于 CSS 的响应式，而是 结构上自适应的布局。

额外小技巧

  • 图片使用相对于容器（table）的 width="100%" 或固定 width 属性
  • 需要层叠或重叠的设计可以通过 图片合并 方式实现（因为 z-index 不可用）
  • 如有必要，可有限度地使用 display: inline-block

结语

完成工作后，我才深感 如果事先了解邮件模板的特性，完全可以大幅减少踩坑。现在即使让 AI 帮忙生成代码或设计，并让它“按邮件兼容性修改”，也能得到相当可观的结果，但离直接上线使用仍有差距。

如果以后还有同事要做邮件模板，希望我的踩坑经历能成为一条 捷径。祝大家顺利！

Back to Blog

相关文章

阅读更多 »