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