table-layout: fixed 能显著提升大表格渲染性能，需显式设置且必须配合列宽声明；auto 模式下浏览器遍历全部内容计算列宽，导致主线程卡顿，fixed 模式仅依赖首行或 width 声明，复杂度从 O(n) 降至 O(1)。
table-layout: fixed 不设等于没开
浏览器默认用 table-layout: auto，遇到 500 行 × 15 列的表格，它得逐行扫描所有 <td> 内容（含长文本、未限制宽的图片、内联样式）来算列宽——这一项就能卡主线程 150ms+。设成 <code>fixed 后，浏览器只看 <col> 或第一行 <th> 的宽度声明，列宽瞬间确定，后续所有行直接按此分配空间。
<ul><li>必须在 <code><table> 上显式写 <code>style="table-layout: fixed"，别指望 reset.css 或父级继承
!important 或提高选择器权重（如 .my-table table）table-layout 是否真为 fixed，搜不到就等于没生效fixed 模式必须配 <col> 才生效
只写 table-layout: fixed 没用。浏览器仍会遍历所有 <td> 内容算列宽，DOM 构建阶段就卡住。必须配合 <code><col> 显式声明宽度，例如：<col style="width: 120px"> <col style="width: auto"> <col style="width: 80px">。
-
width="auto"是合法值，但仅限一列使用；多列设auto会让fixed行为退化回auto - 别在
<th> 或 <code><td> 上用 <code>width属性或style.width——它不参与列宽计算，纯属冗余，还可能干扰编辑器尺寸测量 - SSR 渲染后动态插入
<col>无效：样式已计算完毕；必须在 DOM 构建前就存在 - 响应式改列宽，用
@media控制<col style="width: ...">，不是在单元格里写min-width - 动态加载数据会触发多次重排（layout passes），出现“表格抖动”：列宽频繁变化
-
colspan/rowspan会绕过fixed逻辑，让对应行重新触发布局计算，应禁用 - 避免在
<td> 里用 <code>white-space: normal+ 长无空格字符串；改用word-break: break-word或截断性能差异不只是“快一点”，而是量级变化
1000 行数据实测，
table-layout: fixed渲染速度比auto快约 2 倍。根本原因在算法复杂度：fixed是O(1)，auto是O(n)，n 是总单元格数。当表格嵌套超 4 层、或一次性innerHTML插入 5000 行时，瓶颈不在 JS，而在浏览器 HTML 解析器和渲染引擎被压垮。立即学习“前端免费学习笔记（深入）”；
- 财务报表这类上百列、数千行的场景，
fixed是第一道闸，否则浏览器反复测量每列内容宽度，整表卡住重排 - 虚拟滚动必须配合固定行高，否则编辑器光标定位错乱；别手写滚动监听，用
virtuoso或react-window - 批量插入用
DocumentFragment分批，每 500 行一批，插入后加await new Promise(r => setTimeout(r, 0))让出主线程
- 财务报表这类上百列、数千行的场景，
auto 模式下浏览器要扫完整张表才能开始渲染
table-layout: auto（默认）是内容优先的流式布局：浏览器需遍历所有单元格内容，计算每列最小/最大内容宽度，考虑文本折行、空白处理等复杂情况。60 行 × 12 列的表格，光列宽计算就能卡主线程 100ms+，尤其当单元格含长无空格字符串或未限制宽的图片时。
