innerHTML直接塞大HTML会卡死浏览器，因其解析、构建DOM、样式计算和布局全程同步阻塞主线程，Chrome下超5–10MB即白屏或报RangeError；DocumentFragment分批插入仅缓解layout，不解析卡顿，须配合DOMParser切片（每批200–500节点）并用requestIdleCallback让出主线程。
直接用 innerHTML 插入万行数据或几十MB HTML，不是“慢”，是主线程彻底挂起——连 console.log 都延迟输出，更别说滚动、点击了。
为什么 innerHTML 一塞大 HTML 就卡死
浏览器解析字符串、构建 DOM、计算样式、布局全部同步阻塞主线程。Chrome 下超过 5–10MB 原始 HTML 就大概率白屏或报 RangeError: Maximum call stack size exceeded。这不是 JS 执行慢，是解析器被压垮；DocumentFragment 分批 appendChild 只能缓解 layout 触发，解决不了解析卡顿本身。
- 别指望靠加
async或defer救innerHTML—— 它根本不走脚本加载流程 -
DOMParser解析后切片比直接innerHTML好，但依然要控制每批节点数（200–500 个），不能按字符数切 - 每次批量插入后必须让出主线程：
setTimeout(() => ..., 0)或requestIdleCallback，否则还是卡
table-layout: fixed 必须配 <col> 才生效
没它，浏览器默认用 table-layout: auto，得逐行扫描所有 <td> 内容算列宽，60 行 × 12 列就能卡主线程 100ms+。设了 fixed 却没 <col>，等于没设——浏览器仍会 fallback 到 auto 模式。
-
<col width="120"><col width="80">是唯一可靠方式，width属性写在<th>或<td>上无效且干扰调试 - 禁用
min-width、max-width和内联style.width，它们会让fixed失效 - 响应式列宽用
@media控制<col>的width，别用 JS 动态改——后者强制重排
虚拟滚动不是“可选优化”，而是大数据表格的底线
200 行以上就该上虚拟滚动。哪怕加了 table-layout: fixed，DOM 节点爆炸 + 重绘压力仍会让 FPS 掉到 10 以下。服务端分页只是降低单次载入量，不解决滚动时的渲染压力。
立即学习“前端免费学习笔记（深入）”；
- 只渲染可视区域 ± 1–2 屏的数据，用固定
itemHeight计算scrollTop对应的startIndex - 用
transform: translateY()移动占位容器，避免真实 DOM 节点数量膨胀 - 禁用
loading="lazy"在表格内——它触发距离不可控，容易漏渲染
Checkbox 全选逻辑卡顿和事件绑定陷阱
卡顿主因是 DOM 节点太多，不是 JS 写得差。查一次 querySelectorAll('[name="item_ids"]') 匹配 5000+ 个元素，浏览器遍历就卡住；给每个 <input type="checkbox"> 单独绑 change 监听器，内存泄漏风险高。
- 用事件委托：监听父容器的
change，靠event.target判断是否为目标 checkbox - 全选状态判定必须过滤
disabled元素，否则checkedCount === totalCount会错判 - 不要在每次点击“全选”时重新查全部 checkbox——尤其在虚拟滚动下，只操作当前可视区节点
真正难的不是写分片逻辑，而是判断哪些数据必须前端处理、哪些该压回服务端。比如 CMS 导出的大 HTML，优先在导出时按 <section> 分块；表格数据超 5 万行，后端必须支持分页接口，前端切片只是临时止痛药。
