table-layout: fixed 是唯一能绕过浏览器逐行扫描列宽的硬开关，它使浏览器仅依据第一行或<col>定义确定列宽，将布局时间从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>上必须写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><span>立即学习</span>“<a href="https://pan.quark.cn/s/cb6835dc7db1" style="text-decoration: underline !important; color: blue; font-weight: bolder;" rel="nofollow" target="_blank">前端免费学习笔记（深入）</a>”；</p> <p>实操上必须拆开：用 <code>document.createElement('tr')+DocumentFragment批量构建，每 500–1000 行 append 一次，并主动让出主线程。- 避免
jQuery.html()或element.innerHTML = hugeString - 服务端返回 JSON，而非 HTML 字符串；前端控制渲染节奏
- 每次批量插入后加
await new Promise(r => setTimeout(r, 0))，保持滚动/输入可响应
<thead>和<tbody>不只是语义，更是性能杠杆没
<thead>，浏览器无法对表头做合成层提升（layer promotion）；没<tbody>，滚动时整个表格重绘——这不是“看起来卡”，是 GPU 层面的绘制浪费。动态更新数据时，仅替换
<tbody>内容还不够：如果用了scope或headers关联，新<tr>必须补全headers属性，否则屏幕阅读器和部分 JS 库会失效。- 哪怕只有 1 行表头，也必须包在
<thead>里；主体数据进<tbody> -
<th>必须带scope="col"或scope="row"，不能只靠视觉加粗 - 每次
sort或filter后，要重新生成headers值，比如<td headers="col1 col3">
真正卡住大数据表格的，往往不是数据本身，而是浏览器在布局、DOM 构建、无障碍关联这三个环节反复回溯——
table-layout: fixed解决第一个，分块渲染解决第二个，<thead>/<tbody>+scope解决第三个。漏掉任意一环，优化就打折扣。 - 避免
