根本原因是浏览器默认行为导致重复计算，优化需三步：启用table-layout:fixed、用DocumentFragment分批渲染、实施虚拟滚动并确保语义完整。
大型表格卡顿、错位、无法滚动或语义混乱，根本原因不是数据多，而是浏览器在默认行为下被迫做大量重复计算。关键优化点就三个：table-layout: fixed 必须显式启用，<thead>/<code><tbody> 必须存在，渲染节奏必须由前端主动控制。
<h3>为什么 <code>table-layout: fixed 不设等于没开
浏览器默认用 table-layout: auto，遇到 500 行 × 15 列的表格，它得逐行扫描所有 <td> 内容（含长文本、未限制宽的图片、内联样式）来算列宽——这一项就能卡主线程 150ms+。
<ul><li>必须在 <code><table> 上显式写 <code>style="table-layout: fixed"，别指望 reset.css 或父级继承
<col> 预设宽度，例如：<col style="width: 120px">、<col style="width: auto">
<th> 或 <code><td> 上的 <code>width 属性、style.width，它们不参与 fixed 计算，纯属干扰
@media 控制 <col> 的 width，不是在单元格里写 min-width
一次性 innerHTML 渲染 5000 行 = 主线程假死
不是 JS 慢，是浏览器在 DOM 构建阶段被压垮：字符串解析 + 节点创建 + 回流计算全堆在一次调用里。哪怕你用 document.createElement 单个追加，5000 次 appendChild 也照样卡顿。
- 用
DocumentFragment批量构建，每 500–1000 行插入一次fragment - 每批插入后加
await new Promise(r => setTimeout(r, 0))，让出主线程，保持输入/滚动响应 - 服务端返回 JSON，前端控制节奏；坚决不用
innerHTML = hugeString或jQuery.html() - 若需 XSS 防护，用轻量函数如
escapeHtml()处理字段，别引入重型 sanitizer
虚拟滚动不是“加个 overflow:auto”就完事
只给容器设 display: block 和 overflow-y: auto，DOM 节点还在那儿，浏览器照常解析布局——对 200 行以上毫无意义。
立即学习“前端免费学习笔记（深入）”；
- 必须预设每行高度（或缓存动态高度），否则无法精确计算滚动偏移和占位高度
- 别手写
scroll监听 +innerHTML替换：用virtuoso（Vanilla/TS）或react-window（React），它们已处理IntersectionObserver回退、键盘导航、焦点管理 - 禁用
will-change: transform在滚动容器上——现代浏览器对表格内部元素做该声明反而触发强制图层提升，吃内存 - 后端返回原始数组时，前端别
.map()全量渲染；先按offset+pageSize切片，再喂给虚拟滚动器
语义结构残缺会让所有优化白做
没 <thead> 和 <code><tbody>，浏览器无法对表头做合成层提升，滚动时整个表格重绘；没 <code>scope 或 headers，屏幕阅读器强制遍历所有单元格关联行列，JS 查找也变慢。
<thead> 必须包裹完整的一行或多行表头，<code><tbody> 必须包裹全部数据行 <li><code><th> 必须带 <code>scope="col"或scope="row"，跨行表头用headers显式指向 ID- 避免用
colspan/rowspan破坏行列对齐逻辑，尤其在虚拟滚动场景下，会干扰高度估算
最常被忽略的是：优化必须从服务端接口设计开始——返回结构化分页元信息（total、page_size、offset），而不是让前端硬扛“全量拉取 + 自己切片”。没有这个前提，virtuoso 和 DocumentFragment 都只是打补丁。
