<table>不是“画格子”，而是语义化二维数据结构，必须包含<caption>、<thead>和<tbody>，用<th scope="col/row">明确行列关系，否则导致可访问性断裂、响应式失效；非数据场景应改用Flexbox或Grid。
直接用 <table> 就能创建结构化数据矩阵，但多数人栽在语义缺失、可访问性断裂和响应式失效上。
为什么 <table> 不只是“画格子”
浏览器默认渲染 <table> 时，会按行列逻辑构建 DOM 树，屏幕阅读器依赖 <thead>、<th>、<scope> 等语义标签识别表头与数据关系。纯靠 <tr><td> 堆砌，表格对残障用户就是一串无意义的单元格。
- 缺少
<caption>：表格无标题，WCAG 2.1 AA 级不达标 -
<th>没加scope="col"或scope="row"：多维表头无法被读屏软件正确映射 - 用
<div>+ CSS 模拟表格：语义丢失，打印/导出 Excel 时结构崩溃
<table> 必须包含的最小语义结构
一个可访问、可维护的表格至少要包含 <caption>、<thead> 和 <tbody> —— 即使只有一行数据。
<table>
<caption>2024 年各季度营收（万元）</caption>
<thead>
<tr>
<th scope="col">季度</th>
<th scope="col">华东</th>
<th scope="col">华南</th>
</tr>
</thead>
<tbody>
<tr>
<th scope="row">Q1</th>
<td>128</td>
<td>96</td>
</tr>
</tbody>
</table>
-
<caption>是表格的唯一主标题，不可省略或用<h2>替代 - 列头统一用
<th scope="col">，行头（如 Q1）必须用<th scope="row"> - 即使只有一行数据，
<tbody>也要显式写出 —— 浏览器会自动补全，但手动写明更可控
响应式表格怎么不“挤成一团”
小屏下横向滚动是底线方案，但体验差；真正可用的方式是把二维结构转为单列卡片流，靠 CSS 重排而非隐藏列。
- 避免
overflow-x: auto包裹<table>：触屏滑动卡顿，且无法双指缩放 - 用
@media+display: grid或display: block重构布局，把每行<tr>变成带标签的块级项 - 关键：保留原始
<table>DOM 结构，仅用 CSS 改变视觉呈现 —— 打印、爬虫、读屏仍能获取完整语义
示例思路（简化）：
@media (max-width: 768px) {
table, tbody, tr, th, td { display: block; }
th { position: sticky; left: 0; background: #f5f5f5; }
td::before { content: attr(data-label) ": "; font-weight: bold; }
}
配合在 <td data-label="华东"> 上加属性，就能实现“Q1：华东 128”这样的竖排展示。
什么时候不该用 <table>
当内容没有明确的行列逻辑关系时，<table> 就是错误选择 —— 比如商品列表、人员卡片、表单布局。
- 商品网格：用
<ul>+grid或flex，语义是“列表”，不是“矩阵” - 登录表单：用
<form>+<fieldset>+<label>，表格会破坏 label 关联和键盘导航顺序 - 纯装饰性分隔线/栅格：CSS Grid / Flex 足够，引入
<table>增加 DOM 复杂度和可访问负担
判断标准很简单：能否用“第 X 行第 Y 列”准确描述每个单元格的意义？不能，就别碰 <table>。
