table布局未过时，但仅适用于语义化二维数据展示；滥用会导致首屏延迟、可访问性崩坏和响应式困难；必须用于财务报表、课程表等行列含义明确的数据场景。
table 布局没过时，但用错场景就是技术债。 它不是被淘汰了，而是被正名了：只该出现在真正需要语义化二维数据展示的地方。滥用在页面结构上，会直接拖慢首屏、搞崩可访问性、让响应式变成噩梦。
什么时候必须用 <table>？
当你面对的是天然带行列关系、需对齐、可排序、要被屏幕阅读器正确朗读的数据时，<table> 是唯一合规且最优解。
- 财务报表、API 返回的
[[“2025-01”, 1200], [“2025-02”, 1350]]这类二维数组 - 课程表、航班时刻表、医院排班表——行和列都有明确含义（如
<th scope="col">和<th scope="row">） - 后台管理系统的日志列表、订单明细页，尤其当用户要复制整行/列到 Excel 时
此时不用 <table> 反而是倒退：你得手动模拟语义（比如加 role="grid"），还大概率漏掉 <caption>、summary（已废弃但部分读屏仍依赖）、aria-describedby 等可访问性链路。
为什么 display: table 也不推荐做布局？
它复刻了 <table> 的渲染逻辑，却丢了语义。浏览器依然会等所有“单元格”内容加载完才绘制整块区域，首屏时间照样被卡住。
-
display: table-cell对vertical-align敏感，但对flex或grid中的align-items完全不响应 - 无法用媒体查询单独控制某“列”的显隐，
display: none会破坏整行结构 - IE11 虽支持，但和
position: sticky在table-cell上表现不一致，容易触发重绘 bug
真要兼容 IE11，float + BFC 都比 display: table 更可控——至少它不阻塞渲染。
<table> 用于数据展示时的实操避坑点
哪怕语义正确，写法不对一样翻车。重点不是“能不能用”，而是“怎么用才不埋雷”。
- 别设
height在<table>上——它无效。想固定高度？包一层<div style="height: 400px; overflow: auto;"> -
border-collapse: collapse会让position: sticky的<th>边框变透明，改用border-collapse: separate; border-spacing: 0; - 列宽控制优先用
min-width而非width，否则内容溢出时浏览器会无预警压缩所有列 - 移动端表格横向滚动，必须给父容器设
overflow-x: auto，且<table>不要设width: 100%——它会把滚动条撑出去
最常被忽略的其实是 <caption> 标签：它不是装饰，是屏幕阅读器识别表格用途的第一依据。没有它，再规范的 <th> 也会被当成普通容器处理。另外，cellspacing 和 cellpadding 已是 HTML5 废弃属性，一律改用 CSS 的 border-spacing 和 padding。
