table-layout: fixed 能跳过内容测量是因为浏览器只依据列宽定义或第一行单元格的显式 width 属性计算布局，忽略后续行的内容尺寸，从而大幅减少主线程耗时；但必须配合显式宽度（如 width: 100%）和第一行有效的 width 声明才能生效。
table-layout: fixed 为什么能跳过内容测量
因为浏览器在 fixed 模式下根本不去读后续行的 <td> 内容长度、字体、换行或图片尺寸——它只认两件事：<code><col> 的宽度定义，或者第一行单元格的显式 width 属性（注意：不是 style="width: ..."）。这省掉了 DOM 构建后遍历全部单元格的步骤，对 500 行 × 20 列的表格，光这一项就能减少主线程占用 150ms+。
不写 <col> 就等于没开 fixed
只加 table-layout: fixed 不够，浏览器会 fallback 回 auto 行为。必须配合列宽声明，且优先级是：<col> > 第一行 <th>/<code><td> 的 <code>width 属性 > 平均分配。常见错误包括：
- 在
<th> 上写 <code>style="width: 120px"—— 这不参与列宽计算，纯属无效 CSS - 用
width="120"写在第二行<td> 上 —— 只有第一行才被读取 <li>多个 <code><col width="auto">——auto只能出现在一列，否则整个 fixed 失效 -
<col>插在<thead> 里 —— 它必须是 <code><table> 的直接子节点，否则被忽略 <h3>width: 100% 是 fixed 生效的硬门槛</h3> <p>几乎所有浏览器都要求 <code><table> 元素显式声明宽度，否则即使写了 <code>table-layout: fixed和<col>，也会退回到 auto 模式。这不是可选建议，而是强制条件：- 用内联
style="width: 100%"最可靠，避免被 reset.css 或 UI 库覆盖 - 设
width: 0是个冷技巧：能让未指定宽度的列自动收缩到最小内容宽，适合动态列场景 - 响应式时别用
max-width替代width—— 它不触发 fixed 的列轨道锁定逻辑
colspan 会破坏 fixed 的列对齐基准
第一行出现
colspan会让浏览器无法按列索引映射宽度，导致后续所有行列宽错位、内容溢出或挤压。这不是渲染慢的问题，而是布局崩坏：立即学习“前端免费学习笔记（深入）”；
- 哪怕只有一处
<th colspan="2">，fixed 模式就失去列轨道锚点 <li>解决方案：把带 <code>colspan的表头单独抽成独立<thead>，主数据行从第二行开始，并确保第二行是完整列数的 <code><tr> <li>动态生成表格时，JS 拼接 HTML 前先校验首行是否含 <code>colspan，有则重写结构
固定列宽这件事，本质是用“确定性”换“灵活性”。一旦开了
table-layout: fixed，你就不能再靠内容撑开列宽，所有列宽必须提前可知或可控——这点在财务报表、日志表格等结构稳定但数据量大的场景里，恰恰是最值得牺牲的。 - 用内联
