HTML表格卡顿主因是DOM节点爆炸与主线程阻塞，须采用虚拟滚动（仅渲染视口内±20行）、table-layout:fixed配<col>宽度、分块插入+让出主线程、服务端分页及禁用will-change等综合优化。

HTML表格卡顿不是因为用了

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

，而是你让它一次性干了太多事：建几万节点、反复重排、堵住主线程。解决方向很明确——不让它“一口气做完”。

table-layout: fixed 必须配 <col> 才生效

只写 table-layout: fixed 是无效的。浏览器仍会扫描第一行所有 <td> 内容推导列宽，DOM 构建阶段就卡住。<code><col> 才是唯一参与布局计算的合法元素。

• <col width="120"> <col width="auto"> <col width="80px"> —— 其中 width="auto" 合法但仅限一列；多列设 auto 会让 fixed 失效
• 禁用在 <th> 或 <code><td> 上写 <code>width 属性或 style.width：它们不参与布局，纯属冗余且干扰调试
• 响应式列宽？用 @media 控制 <col> 的 width，别用 JS 动态改 style —— 后者强制同步重排
• SSR 渲染后动态插入 <col> 无效：样式已计算完毕，宽度不会回溯更新

分块插入必须让出主线程，否则白屏假死

一次性插入 5000 行 <tr>，哪怕用 <code>DocumentFragment，也会触发多次重排 + 字符串解析开销，页面直接冻结。关键不是“怎么插”，而是“插完立刻放手”。

• 每批插入 500–1000 行后，加 await new Promise(r => setTimeout(r, 0)) 或 requestIdleCallback 让出主线程
• 禁用 innerHTML = str 拼接大段 HTML：XSS 风险高，且字符串解析本身耗 CPU
• 服务端必须返回 JSON，而非 HTML 字符串；前端控制渲染节奏，而不是把渲染压力甩给后端模板
• 清空 <tbody> 后再批量插入，别用循环 + <code>appendChild —— 那是单点阻塞源

  超过 200 行就必须用虚拟滚动

  display: block + overflow-y: auto 加固定高度只是障眼法。DOM 还在那儿，浏览器照样解析、布局、绘制。真正有效的只有虚拟滚动：只渲染视口内 ±20 行，其余用占位 <tr> 填充高度。<p><span>立即学习</span>“<a href="https://pan.quark.cn/s/cb6835dc7db1" style="text-decoration: underline !important; color: blue; font-weight: bolder;" rel="nofollow" target="_blank">前端免费学习笔记（深入）</a>”；</p> <ul> <li>行高必须固定（如 <code>height: 42px），否则无法精确计算滚动偏移与可视索引

• 别手写滚动监听 + textContent 替换 —— 用 virtuoso（Vanilla/TS）或 react-window（React），它们已处理好 IntersectionObserver 回退、键盘导航、焦点管理
• 禁用 will-change: transform 在滚动容器上：现代浏览器对表格内部元素做该声明反而触发强制图层提升，增加内存开销
• <thead> 和 <code><tbody> 分层不可省：没 <code><thead>，浏览器无法对表头做合成层提升，滚动时整个表格重绘 <p>最常被忽略的是：虚拟滚动不是“开了就灵”，它依赖预设行高和 DOM 节点数严格受控。一旦允许动态高度或未隔离 <code><thead>，性能收益归零。</thead>