HTML邮件开发中唯一可靠的是表格布局标签（<table><tr><td><th>），配合内联CSS、<font>字体控制及兼容性处理，因主流邮箱客户端渲染引擎陈旧且差异极大。
主流邮箱对 HTML 邮件的支持差异极大，<div>、<section>、<flex> 这类现代布局标签基本不可靠，能安全用的只有十几年前的“表格布局时代”遗留标签 —— 不是设计限制，是客户端渲染引擎长期停滞导致的现实。
哪些 HTML 标签在绝大多数邮箱里真能用
不是“语法合法”，而是“渲染一致且可控”。实测（2024 年主流客户端：Outlook Desktop（Windows）、Outlook Web、Gmail（Web/iOS/Android）、Apple Mail、Yahoo Mail）中稳定支持的标签极少：
-
<table>、<tr>、<td>、<th>：唯一可靠的布局方案，连<tbody>都有部分 Outlook 版本忽略 -
<p>、<span>、<br>：文本流控制可用，但<p>的默认 margin 在 Gmail 和 Outlook 中差异明显 -
<a>：必须带href，且建议加target="_blank"（Gmail 会自动补，但 Apple Mail 不会） -
<img>：需含alt、明确width/height属性（避免重排），display: block写在内联 style 里防 Outlook 多出间隙 -
<font>：别笑，它比style="font-family: ..."在旧版 Outlook 中更可靠；Gmail 已不支持<font>，但会降级为默认字体而非崩坏
为什么 inline CSS 是唯一可行的样式方案
外部 CSS、<style> 块、甚至 @media 查询，在多数客户端中被剥离、忽略或触发安全策略拦截。Gmail 会移除整个 <style> 标签；Outlook Desktop（基于 MS Word 渲染引擎）只认极少数内联属性，比如 color、font-size、text-align，但不支持 margin 或 padding（用 <table> 单元格 cellpadding/cellspacing 替代）。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 所有关键样式必须写进
style属性，例如：<td style="font-family: Arial, sans-serif; color: #333;"> - 避免简写属性：
margin: 10px 0可能被截断，拆成margin-top: 10px; margin-bottom: 10px; - 背景图？仅 Yahoo 和 Apple Mail 支持
background-image，Outlook 和 Gmail 完全不渲染，必须用<img>拼接 - 字体栈要保守：
"Helvetica Neue", Helvetica, Arial, sans-serif是安全底线；系统字体如 “SF Pro Display” 在 Gmail 中直接回退到 Times New Roman
常见错误现象与对应修复点
发完测试邮件后发现错位、文字叠在一起、图片消失 —— 这些不是代码写错了，而是某客户端主动改了你的 DOM：
立即学习“前端免费学习笔记（深入）”；
-
Gmail 移除
<head>和所有<style>：把原本在<head>里的 reset 样式全部复制到每个元素的style属性里 -
Outlook Desktop 把
<div>当成换行符处理：哪怕写了display: inline-block，也会强制换行，一律换成<table>套嵌 -
Apple Mail 忽略
max-width：响应式邮件中用width="600"固定主容器宽度，再配合<meta name="viewport">（仅 iOS Mail 有效，其他无视） -
链接点击区域异常小：在
<a>外层套<table>+<td>，并设padding，因为纯内联padding在 Outlook 中无效
真正难的不是写出能跑的 HTML，而是让同一份代码在 7 个不同渲染引擎下看起来“差不多”。那些被删掉的语义化标签、被忽略的 flex 布局、永远对不齐的像素——不是你技术不行，是邮箱客户端集体选择停留在 IE5 时代。动手前先查 Can I Email，别信“HTML5 邮件”的营销话术。
