table-layout: fixed 必须显式声明在 table 标签上，搭配 预设宽度，禁用单元格 width；万行表格需用 documentfragment 分批（500–1000 行）插入并 requestanimationframe 节流，配合固定行高虚拟滚动与 dom 复用池。
table-layout: fixed 必须显式声明，否则列宽计算卡死主线程
浏览器默认用 table-layout: auto，面对万行表格时会逐行扫描所有 <td> 内容（含长文本、未设宽图片）来推算列宽，单次计算可能阻塞主线程 150ms+。这不是 JS 慢，是 DOM 构建阶段被压垮。<ul><li>必须在 <code><table> 标签上直接写 <code>style="table-layout: fixed"，reset.css 或父级样式无法继承生效
<col> 预设宽度：<col style="width: 120px">
<col style="width: auto">，第一行 <tr> 的 <code><td> 宽度会被忽略<li>禁用 <code><th> 和 <code><td> 上的 <code>width 属性或 style.width，它们不参与 fixed 计算，反而干扰布局@media 控制 <col> 的 width，别在单元格里写 min-width
万行表格不能一次性 innerHTML 渲染
哪怕字符串拼接再快，innerHTML = hugeString 也会触发完整解析 + 节点创建 + 回流计算，主线程直接假死。实测 5000 行就可能让 8GB 内存笔记本卡顿超 2 秒。
- 用
DocumentFragment批量构建，每批控制在 500–1000 行；太多仍卡，太少调度开销占比高 - 每批插入后加
await new Promise(r => setTimeout(r, 0))，主动让出主线程，保持滚动/输入响应 - 服务端返回 JSON，前端控制节奏；坚决不用 jQuery.html() 或直接赋值
innerHTML - 若需 XSS 防护，用轻量函数如
escapeHtml()处理字段，别引入重型 sanitizer
虚拟滚动必须配固定行高 + 缓冲区，否则白屏跳帧
动态行高会让 startIndex = Math.floor(scrollTop / rowHeight) 失效，导致错位、重复渲染或快速滚动时大面积空白——这不是 bug，是数学模型崩了。
-
rowHeight设为固定值（如48），避免运行时反复测量；大屏监控场景中统一高度比“自适应”更可控 -
bufferCount至少为Math.ceil(viewportHeight / rowHeight) + 2，保证上下各多渲染两屏；只加顶部缓冲、忽略底部，滚到底部必卡 - 撑高容器用的
phantomHeight必须严格等于totalCount * rowHeight，否则滚动条比例失真 - 滚动监听必须用
requestAnimationFrame节流，onscroll在高刷屏上可能每帧触发多次计算
DOM 复用池比虚拟滚动更关键，createElement 是性能黑洞
虚拟滚动只解决“不渲染不可见行”，但滚动时仍高频调用 document.createElement('tr')——每次触发内存分配 + 样式树挂载 + layout → paint 全链路，GC 压力爆炸。
- 池大小建议设为可视区域行数 × 2～3（如视口显示 20 行，池配 40～60 个
<tr>）；过大拖慢 GC，过小频繁回收<li> <code>recover()必须清空textContent和innerHTML，否则旧数据残留导致错行 - 不要在
createFn里绑定事件监听器；应在取出后按需绑定，回收前用removeEventListener解绑 - 对带
dataset或内联样式的<td>，回收时也要重置 <code>node.dataset.key = ''和node.style.cssText = ''真实项目中最容易被忽略的，是复用池里的节点没真正“断引用”：哪怕调了
remove()，只要 JS 变量还持有它，或者闭包里持续读取offsetTop，这个节点就永远活在堆里。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
