在邮件中未被淘汰是因为它是唯一跨客户端稳定渲染的布局方案。Outlook用Word引擎不支持Flex，Gmail剥离style标签，iOS Mail媒体查询不稳定；table属性如width、align原生可靠，且禁用CSS仍可读；现代工具链输出仍是规范table结构。
不是倒退，是必要妥协。现代 CSS 布局（Flex、Grid）在多数邮件客户端里根本不可用——Gmail 会剥离 style 标签，Outlook Desktop（基于 Word 渲染引擎）不支持 display: flex，Apple Mail 对 @media 查询的支持也极不稳定。用 table 不是因为怀旧，而是因为它是目前唯一能跨客户端稳定控制宽度、对齐和堆叠行为的方案。
为什么 <table> 在邮件里还没被淘汰
邮件客户端的渲染引擎五花八门：Outlook 用 Word，Gmail（网页版）会过滤内联样式以外的 CSS，iOS Mail 虽然支持部分现代特性，但对嵌套 div 的 margin/padding 解析常出错。而 <table> 是所有客户端原生支持的、无条件渲染的 HTML 元素。
-
width、align、cellpadding、cellspacing这些属性至今被完整保留且可靠生效 - 即使禁用 CSS，
<table>结构仍能维持基本可读性（不像 Flex 崩溃后变成垂直堆叠乱序） - 主流邮件工具链（如
Maizzle、Foundation for Emails）生成的最终 HTML 仍是table嵌套结构，只是帮你写得更规范
table 布局必须配合的实操约束
盲目套用老式 <table width="600"> 会踩坑。关键不是“用不用”，而是“怎么用”：
- 必须设
role="presentation"属性，明确告诉屏幕阅读器这不是语义化表格，避免无障碍问题 - 所有宽度优先用
width属性（而非 CSSwidth），例如<td width="300">；Outlook会忽略style="width: 300px" - 避免
colspan/rowspan复杂合并——某些 Android 客户端解析错位，宁可用嵌套<table>拆分 - 响应式靠媒体查询 +
max-width+width: 100% !important组合，但只作用于最外层<table>；内部单元格改用width="100%"配合min-width内联样式兜底
什么时候可以不用 <table>？
极有限场景下，div + 基础 CSS 是可行的，但需严格验证：
- 纯文本邮件或轻量通知类模板（如密码重置），只在
Gmail App、iOS Mail、Spark等较新客户端中投递，且不兼容Outlook—— 这类需求极少 - 内嵌在企业内网邮件系统（如定制化
ExchangeWeb Client）中，已知其渲染引擎支持现代 CSS - 用
HTML email做登录页跳转载体（非直接展示），此时样式容错率高，可大胆用div
只要目标用户包含使用 Outlook Desktop 或国内企业邮箱（如网易企业邮、腾讯企业邮旧版），<table> 就仍是事实标准。别被“语义化”“现代化”带偏——发不出去的邮件，再漂亮也没意义。
