table-layout: fixed 必须显式设置在 <table> 标签的 style 属性中，并配合 <col> 定义列宽，才能避免浏览器自动计算导致的布局卡顿；长文本需加 word-break: break-word，大批量渲染应使用 DocumentFragment 批量插入并让出主线程，虚拟滚动须预设行高、复用节点，且语义结构（如 <thead>/<tbody> 和 scope）不可缺失。
table-layout: fixed 必须显式设置在 <table> 上
不设 table-layout: fixed，浏览器默认用 auto 模式，会逐行扫描所有 <td> 内容（含长文本、未限制宽的图片）来算列宽——500 行 × 15 列就可能卡主线程 150ms+。这不是 JS 慢，是布局引擎被拖住。
-
table-layout: fixed必须写在<table>标签的style属性里，例如：style="table-layout: fixed; width: 100%;"；靠 CSS 类、reset.css 或父级继承都不可靠 - 列宽必须由
<col>标签定义，比如：<col style="width: 120px"><col style="width: auto">；<th>或<td>上的width属性或style.width不参与计算，纯属干扰 - 响应式列宽改用
@media控制<col>的width，别在单元格里写min-width或flex - 长文本需加
word-break: break-word到<td>，否则会撑破固定列宽
避免一次性 innerHTML 渲染几千行
哪怕你用 document.createElement('tr') 循环 5000 次再 appendChild，也会因频繁 DOM 操作触发同步重排，页面假死。关键不是“怎么建节点”，而是“怎么批量交出去”。
- 用
DocumentFragment批量构建，每 500–1000 行插入一次fragment到<tbody> - 每次插入后加
await new Promise(r => setTimeout(r, 0))，主动让出主线程，保持滚动/输入响应 - 服务端返回 JSON，前端控制节奏；坚决不用
innerHTML = hugeString或jQuery.html() - 若需 XSS 防护，用轻量函数如
escapeHtml()处理字段，别引入重型 sanitizer
虚拟滚动必须预设行高且复用节点
只给容器设 overflow-y: auto，但 DOM 节点全在那儿，对 200 行以上毫无意义。虚拟滚动不是 CSS 技巧，是 JS 层的数据映射与节点复用逻辑。
- 必须预设每行高度（如
32px），否则无法精确计算滚动偏移和占位高度；动态高度需缓存，首次渲染慢、内存占用高，90% 场景用固定高度就够了 - 不要每次滚动都
innerHTML = ''再拼接；预先创建固定数量的<tr>节点池，滚动时仅更新textContent和dataset.rowIndex - 定位用
transform: translateY(${startIndex * itemHeight}px)，比top或paddingTop更可靠，不触发重排 - 容器内需有一个撑高元素：
height: ${totalItems * itemHeight}px；别用position: absolute + top，快速滚动易跳动
语义结构残缺会让所有优化白做
没 <thead> 和 <tbody>，浏览器无法对表头做合成层提升，滚动时整个表格重绘；没 scope 或 headers，屏幕阅读器强制遍历所有单元格关联行列，JS 查找也变慢。
立即学习“前端免费学习笔记（深入）”；
- 哪怕只有 1 行表头，也必须包在
<thead>里，数据进<tbody>；页脚用<tfoot> -
<th>必须带scope="col"（列头）或scope="row"（行头），不能只靠视觉加粗 - 每次动态更新
<tbody>（比如筛选、排序），要重新补全headers属性，否则无障碍支持断裂 - 不要把
data-*属性当成性能解药：它不减少 DOM 节点数，也不控制渲染时机；只应在虚拟滚动中绑定当前可视项的真实业务标识，比如data-order-id
真正卡顿的从来不是数据量本身，而是浏览器被迫反复重排——列宽没锁死、DOM 一次性塞满、表头没分层、滚动没复用节点，这些细节一漏，再快的机器也扛不住。
