不该用 table 做布局，因其语义上专用于二维数据；仅在课程表等真实表格场景中可用，且须含 caption、thead/tbody、th[scope] 等语义结构。
不该用 table 做布局，这是明确结论。它不是“能不能”，而是“语义上就不该”——浏览器、屏幕阅读器、搜索引擎都按数据表格理解 table，硬拿它排版会直接破坏结构可读性。
为什么 table 布局在现代前端中是反模式
当你写 <table><tr><td><div class="header"></div></td></tr></table> 这类代码时，问题不在“能不能显示出来”，而在于：
- 屏幕阅读器会把整个页面读成一张“有 1 行 1 列的空表格”，
header区域失去语义身份 -
colspan和rowspan嵌套越深，CSS 响应式断点越难控制，移动端常出现横向滚动或错位 - SEO 爬虫无法识别
<td>里的内容层级，<main>或<aside>的权重被稀释 - 维护时改个侧边栏宽度，可能要同时调
<colgroup>、td的width属性、内联样式三处
table 什么情况下必须用，且要怎么语义化
真正二维数据场景下，table 不仅可用，而且是唯一正确选择：课程表、财务报表、API 响应字段对照表等。关键在结构补全：
- 必须包含
<caption>，不能只靠视觉标题；它会被屏幕阅读器优先朗读 -
<thead>只放列头，<tbody>放数据，<tfoot>放合计行（即使 DOM 顺序在tbody后，渲染仍可置底） -
<th>必须带scope="col"或scope="row"，否则辅助工具无法建立行列关联 - 避免
rowspan/colspan超过 2 层；复杂表头优先用id+headers显式绑定，比如<td headers="month q1 q2">
示例片段：
立即学习“前端免费学习笔记（深入）”；
<table>
<caption>2025 Q1 各地区销售额（万元）</caption>
<thead>
<tr>
<th scope="col">地区</th>
<th scope="col" id="q1">Q1</th>
<th scope="col" id="q2">Q2</th>
</tr>
</thead>
<tbody>
<tr>
<th scope="row">华东</th>
<td headers="q1">420</td>
<td headers="q2">480</td>
</tr>
</tbody>
</table>
替代 table 布局的 CSS 方案选型依据
不用 table 布局，不等于随便套个 flex 就完事。得看结构维度和动态需求：
- 单行/单列排列（导航栏、按钮组、卡片流）→ 用
display: flex，flex-wrap控制换行，gap替代 margin 冗余 - 网格状固定区域（后台仪表盘、商品列表、表单字段对齐）→ 用
display: grid，配合grid-template-areas命名区域，逻辑比嵌套div清晰十倍 - 需要语义区块（页眉、主内容、侧边栏、页脚）→ 直接用
<header>、<main>、<aside>、<footer>，再用 CSS 定位，无需额外容器 - 表单字段对齐这种“伪表格”需求 → 用
dl+dt/dd更语义，CSS Grid 控制左右间距，比模拟table更轻量
容易被忽略的兼容性与可访问性细节
很多人以为“能显示”就等于“可用”，但以下三点实际项目里高频出问题：
-
<caption>必须紧贴<table>开始标签后，中间不能有注释或空格，否则部分旧版 JAWS 会跳过 - Flex/Grid 布局中，若用
order或grid-area改变视觉顺序，务必同步调整 DOM 顺序或加aria-flowto，否则键盘 Tab 顺序和屏幕阅读器流不一致 - 用
dl替代表格展示参数时，别忘了给<dt>加role="term"、<dd>加role="definition"，iOS VoiceOver 对原生dl的支持仍有碎片化
语义不是加几个标签就完事，而是让每个标签都承担它本该承担的职责。布局归 CSS，语义归 HTML，混用只会让两者都失效。
