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