在邮件中未被淘汰是因为它是唯一跨客户端稳定渲染的布局方案。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> 在邮件里还没被淘汰 <p>邮件客户端的渲染引擎五花八门：<code>Outlook 用 Word，Gmail（网页版）会过滤内联样式以外的 CSS，iOS Mail 虽然支持部分现代特性，但对嵌套 div 的 margin/padding 解析常出错。而 <table> 是所有客户端原生支持的、无条件渲染的 HTML 元素。 <ul> <li> <code>width、align、cellpadding、cellspacing 这些属性至今被完整保留且可靠生效

即使禁用 CSS，<table> 结构仍能维持基本可读性（不像 Flex 崩溃后变成垂直堆叠乱序） <li>主流邮件工具链（如 <code>Maizzle、Foundation for Emails）生成的最终 HTML 仍是 table 嵌套结构，只是帮你写得更规范

table 布局必须配合的实操约束

盲目套用老式 <table width="600"> 会踩坑。关键不是“用不用”，而是“怎么用”： <ul> <li>必须设 <code>role="presentation" 属性，明确告诉屏幕阅读器这不是语义化表格，避免无障碍问题

所有宽度优先用 width 属性（而非 CSS width），例如 <td width="300">；<code>Outlook 会忽略 style="width: 300px"

避免 colspan/rowspan 复杂合并——某些 Android 客户端解析错位，宁可用嵌套 <table> 拆分 <li>响应式靠媒体查询 + <code>max-width + width: 100% !important 组合，但只作用于最外层 <table>；内部单元格改用 <code>width="100%" 配合 min-width 内联样式兜底

什么时候可以不用 <table>？ <p>极有限场景下，<code>div + 基础 CSS 是可行的，但需严格验证：

• 纯文本邮件或轻量通知类模板（如密码重置），只在 Gmail App、iOS Mail、Spark 等较新客户端中投递，且不兼容 Outlook —— 这类需求极少
• 内嵌在企业内网邮件系统（如定制化 Exchange Web Client）中，已知其渲染引擎支持现代 CSS
• 用 HTML email 做登录页跳转载体（非直接展示），此时样式容错率高，可大胆用 div

只要目标用户包含使用 Outlook Desktop 或国内企业邮箱（如网易企业邮、腾讯企业邮旧版），<table> 就仍是事实标准。别被“语义化”“现代化”带偏——发不出去的邮件，再漂亮也没意义。</table>