table-layout: fixed 必须显式声明，否则浏览器默认用 auto 模式逐行扫描内容推算列宽，导致大表格卡顿；设为 fixed 后仅读第一行即确定列宽，需直接在 table 上写 style="table-layout: fixed" 并配合 col 预设宽度。
table-layout: fixed 必须显式声明，否则等于没开
浏览器默认用 table-layout: auto，面对 500 行 × 15 列的表格，它会逐行扫描所有 <td> 内容（含长文本、未限制宽的图片）来推算列宽——单次计算就可能卡主线程 150ms+。<code>table-layout: fixed 一设，浏览器只看第一行或 <col>，列宽瞬间确定。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 必须在
<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 - 用
DocumentFragment批量构建，每 500–1000 行插入一次fragment - 每批插入后加
await new Promise(r => setTimeout(r, 0))，让出主线程，保持输入/滚动响应 - 服务端返回 JSON，前端控制节奏；坚决不用
innerHTML = hugeString或jQuery.html() - 若需 XSS 防护，用轻量函数如
escapeHtml()处理字段，别引入重型 sanitizer -
rowHeight设为固定值（如48），避免运行时反复测量 -
bufferCount至少为Math.ceil(viewportHeight / rowHeight) + 2，保证上下各多渲染两屏 - 撑高容器用的
phantomHeight必须严格等于totalCount * rowHeight，否则滚动条比例失真 - 滚动监听必须用
requestAnimationFrame节流，而非直接写在onscroll里 - 对深度 > 12 的容器（如嵌套表格、多级折叠面板），优先用
el.replaceChildren()替代innerHTML = '' -
replaceChildren()强制同步销毁旧子节点及其样式上下文，比innerHTML或textContent更彻底切断引用路径 - IE 不支持，但 Chrome 86+、Firefox 76+、Safari 14.1+ 和鸿蒙 ArkTS 均已原生支持；旧环境可用
while (el.firstChild) el.removeChild(el.firstChild)手动清空 - 若缓存了某个深层节点，清空 DOM 后务必置
cachedNode = null，否则整个祖先链仍驻留内存
一次性 innerHTML 渲染万行 = 主线程假死
不是 JS 慢，是浏览器在 DOM 构建阶段被压垮：字符串解析 + 节点创建 + 回流计算全堆在一次调用里。哪怕你用 document.createElement 单个追加，5000 次 appendChild 也照样卡顿。
实操建议：
立即学习“前端免费学习笔记（深入）”；
虚拟滚动必须预设固定行高 + 缓冲区
动态行高（如自动换行文本）会让 startIndex = Math.floor(scrollTop / rowHeight) 失效，导致错位、白屏或重复渲染。工业级方案要么预估平均高度并缓存实际高度（Layout Cache），要么强制统一行高——后者在大屏监控中更可控、更易调试。
实操建议：
立即学习“前端免费学习笔记（深入）”；
DOM 树深度 > 12 时 replaceChildren() 比 innerHTML 更安全
innerHTML = '' 清空后旧节点可能滞留在内存中，尤其当这些节点曾被 JS 变量缓存过——深层 DOM 中 parentNode 链断裂后仍隐式持有引用，是隐蔽的内存驻留陷阱。
实操建议：
立即学习“前端免费学习笔记（深入）”；
