table-layout: fixed 是唯一能绕过浏览器逐行扫描列宽的硬开关，它使浏览器仅依据第一行或定义确定列宽，将布局时间从o(n×m)降至o(m)，避免主线程阻塞。
table-layout: fixed 是唯一能绕过浏览器逐行扫描列宽的硬开关，不设它，60 行 × 12 列的表格光布局阶段就卡主线程 100ms+。
为什么 table-layout: fixed 必须显式声明
浏览器默认用 auto 模式计算列宽：它得遍历所有 <td> 内容（含长文本、未约束图片、内联样式），逐行比对才能确定最终列宽。数据量一上来，这个过程不是“慢”，而是“阻塞”——主线程被锁死，用户无法滚动、输入、点击。
<p>设成 <code>fixed 后，浏览器只看第一行 <tr> 或 <code><col> 定义，列宽瞬间拍板，后续所有行直接按此分配空间，布局时间从 O(n×m) 降到 O(m)。
- 别依赖 reset.css 或父级继承，
<table> 上必须写 <code>style="table-layout: fixed"或 CSS 类明确声明 -
<col>比 CSS 类更可靠：<col style="width: 120px"> <col style="width: 80px">，浏览器优先读它 - 禁用
<td width="..."> 和 <code>min-width，它们会干扰fixed的宽度推导逻辑一次性
innerHTML插入万行表格的假死真相不是 JS 慢，是浏览器在 DOM 构建阶段被压垮了。6 万行
<tr> 字符串解析 + 节点创建 + 重排重绘，主线程连续占用超 30 秒，页面彻底无响应。 <p>实操上必须拆开：用 <code>document.createElement('tr')+DocumentFragment批量构建，每 500–1000 行 append 一次，并主动让出主线程。- 避免
jQuery.html()或element.innerHTML = hugeString - 服务端返回 JSON，而非 HTML 字符串；前端控制渲染节奏
- 每次批量插入后加
await new Promise(r => setTimeout(r, 0))，保持滚动/输入可响应
<thead> 和 <code><tbody> 不只是语义，更是性能杠杆 <p>没 <code><thead>，浏览器无法对表头做合成层提升（layer promotion）；没 <code><tbody>，滚动时整个表格重绘——这不是“看起来卡”，是 GPU 层面的绘制浪费。 <p>动态更新数据时，仅替换 <code><tbody> 内容还不够：如果用了 <code>scope或headers关联，新<tr> 必须补全 <code>headers属性，否则屏幕阅读器和部分 JS 库会失效。- 哪怕只有 1 行表头，也必须包在
<thead> 里；主体数据进 <code><tbody><li><code><th> 必须带 <code>scope="col"或scope="row"，不能只靠视觉加粗 - 每次
sort或filter后，要重新生成headers值，比如<td headers="col1 col3"> <p>真正卡住<a style="color:#f60; text-decoration:underline;" title="大数据" href="https://m.php.cn/zt/16141.html" target="_blank">大数据</a>表格的，往往不是数据本身，而是浏览器在布局、DOM 构建、无障碍关联这三个环节反复回溯——<code>table-layout: fixed解决第一个，分块渲染解决第二个，<thead>/</thead> <tbody> + <code>scope解决第三个。漏掉任意一环，优化就打折扣。
- 避免
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
