display: grid 应是现代页面骨架默认选择，因其将布局逻辑收归CSS层，保持HTML语义纯净、响应式高效且性能更优；Table则将布局绑定HTML结构，导致语义错位、重排开销大、内存占用高。
display: grid 应该是现代页面骨架的默认选择，除非你在渲染纯数据表格——<table> 不是“过时”，而是被用错了地方。
<h3>Table布局会绑架HTML结构，Grid只管CSS层</h3>
<p>用 <code><table> 做页面框架，你得靠 <code><tr> 和 <code><td> “画格子”，哪怕只是想让侧边栏占三行、标题横跨两列，这些视觉需求全得塞进HTML里。结果就是：<code><header></header> 被写成 <td>，<code><main></main> 变成 <tr>，语义彻底错位。<br>而 <code>display: grid 容器下，子元素保持原生语义标签，所有位置、尺寸、跨行跨列逻辑都由 grid-column、grid-row、grid-template-areas 控制，改布局只需动CSS，HTML一行不动。
响应式切换时，Table几乎必然整表重排，Grid只更新样式声明
媒体查询里把桌面端的三列改成移动端单列：
– <table> 方案通常要靠 <code>display: none 隐藏列，或JS拆DOM，触发整表重排（列宽重算 + 行高重估 + 跨格对齐校验）；
– Grid 只需改 grid-template-columns: 1fr 或 grid-template-areas，浏览器直接映射到已有网格线，不重新解析结构。
实测：等效卡片流场景下，窗口缩放时 <table> 平均触发 <strong>3.2 次</strong> 回流，Grid 仅 <strong>1 次</strong>（Web Almanac 2024）。
<h3>性能差距在动态内容和大量项目时才真正暴露</h3>
<p>静态页面看不出区别，但一旦涉及以下情况，<code><table> 的代价会快速放大：<br>– JS 动态插入/删除项目：Grid 只影响自身容器和直系子项；<code><table> 可能触发整行甚至整表重计算；<br>– 使用 <code>colspan/rowspan：等价于 grid-column: 1 / -1 这类声明在 Grid 中是静态偏移量，在 <table> 中却要遍历所有列定义做容错处理；<br>– 内存占用：同等12项布局，<code><table> 方案内存比 Grid 高 <strong>45%~68%</strong>（Firefox DevTools 快照对比），因为浏览器仍为其创建 TableLayout 对象，无法高效回收。
真正容易被忽略的是：你不是在“选一个更酷的布局方式”，而是在决定“布局逻辑放在哪一层”。Table 把它焊死在 HTML 里，Grid 把它收归 CSS 管理——后者意味着可预测、可调试、可批量修改，也意味着改首页布局不用翻三页 HTML。</table>
