table-layout: fixed 必须配合显式列宽定义（如col标签或第一行width）才生效，否则浏览器仍按auto模式逐行扫描内容导致卡顿；需结合语义结构、虚拟滚动及分批渲染才能实现高性能表格。
table-layout: fixed 必须显式声明且配 <col> 才生效
只写 table-layout: fixed 不起作用。浏览器仍会走默认的 auto 模式，逐行扫描所有 <td> 内容（含长文本、图片、内联样式）来推导列宽——500 行 × 12 列表格光这一步就能卡主线程 100ms+。真正触发 fixed 布局的，是 <code><col> 标签或第一行 <th> 的 <code>width 属性（但后者不推荐）。
实操建议：
- 在
<table> 标签上直接加内联样式：<code>style="table-layout: fixed; width: 100%;"，别依赖外部 CSS 类或 reset.css - 插入
<col>作为<table> 的第一个子节点，例如：<code><col style="width: 150px"> <col style="width: auto"> <col style="width: 80px"> -
width="auto"合法，但仅限一列；多列设auto会让 fixed 失效 - 删掉所有
<th> 和 <code><td> 上的 <code>width属性或style.width——它们不参与 fixed 计算，纯属干扰一次性 innerHTML 渲染千行表格 = 主线程假死
不是 JS 慢，是浏览器在 DOM 构建阶段被压垮：字符串解析 + 节点创建 + 回流计算全堆在一次调用里。哪怕你用
document.createElement('tr')循环 1000 次appendChild，照样卡顿。实操建议：
- 用
DocumentFragment批量构建每 500–1000 行，再一次性挂载到<tbody> <li>每批插入后加 <code>await new Promise(r => setTimeout(r, 0))，让出主线程，保持滚动/输入响应 - 服务端返回 JSON，前端控制节奏；坚决不用
innerHTML = hugeString或jQuery.html() - 若需 XSS 防护，用轻量函数如
escapeHtml()处理字段，别引入重型 sanitizer
虚拟滚动不是加
overflow-y: auto就完事只给容器设
display: block和overflow-y: auto，DOM 节点还在那儿，浏览器照常解析布局——对 200 行以上毫无意义。真正有效的虚拟滚动，只渲染视口内 ±1～2 屏的数据行，其余用占位<tr> 填充高度。 <p>实操建议：</p> <ul> <li>必须预设每行高度（如 <code>height: 42px），否则无法精确计算滚动偏移和占位高度 - 用
- 别手写
scroll监听 +innerHTML替换：用virtuoso（Vanilla/TS）或react-window（React），它们已处理 IntersectionObserver 回退、键盘导航、焦点管理 - 禁用
will-change: transform在滚动容器上——现代浏览器对表格内部元素做该声明反而触发强制图层提升，吃内存 - 后端返回原始数组时，前端别
.map()全量渲染；先按offset + pageSize切片，再喂给虚拟滚动器
语义结构残缺会让所有优化白做
没 <thead> 和 <code><tbody>，浏览器无法对表头做合成层提升，滚动时整个表格重绘；没 <code>scope 或 headers，屏幕阅读器强制遍历所有单元格关联行列，JS 查找也变慢。哪怕只有 1 行表头，也必须包在 <thead> 里，数据进 <code><tbody>。
<p>实操建议：</p>
<ul><li>表头必须用 <code><th>，并带 <code>scope="col" 或 scope="row"；复杂表用 id + headers 显式关联
<caption></caption> 不可省，它既是语义锚点，也是 SEO 和可访问性关键<td> 里嵌套 <code><div> 或 <code><span></span> 来“撑开”内容——破坏 fixed 布局，触发回流
@media 控制 <col> 的 width，不是在单元格里写 min-width
table-layout: fixed 当成开关一开就万事大吉——它只是起点，<col> 宽度定义、语义分层、虚拟滚动的行高预设，三者缺一不可。任何环节松动，大数据量下都会在某个环节突然卡住。
