虚拟滚动四要素缺一不可：控制DOM数量、固定布局、让出主线程、服务端分页；table-layout:fixed需配合显式列宽，响应式用@media；分片必须后端支持；超200行应改用块级虚拟滚动。

直接用 innerHTML 渲染万行表格必然卡死，虚拟化不是“加个库就行”，而是必须控制 DOM 数量、固定布局、让出主线程、配合服务端分页——四者缺一不可。

为什么 table-layout: fixed + 是硬性前提

只写 table-layout: fixed 毫无作用。浏览器仍会扫描第一行所有 <td> 内容推导列宽，重排照旧。真正生效的唯一方式是显式定义 <code><col>：

• <col width="120">、<col width="80px"> 等数值单位必须明确，不能靠 style.width 或 <td width="..."> 补救 <li> <code>width="auto" 仅允许出现在**至多一列**中；多列设 auto，table-layout: fixed 直接失效
• 响应式列宽改用 @media 控制 <col width>，别用 JS 动态改 style——后者强制重排

分片加载必须走服务端分页，而非前端 slice()

前端对 5 万行 JSON 做 data.slice() 是伪优化：JSON 解析 + 数组切片本身已成瓶颈，且用户无法跳转末页。真实分片依赖后端接口支持：

• 请求参数必须含 page=3&size=50，而非传全部数据再本地切
• 后端返回结构必须含 list: [...] 和 total: 49821 字段
• 前端拿到后，**立刻清空 <tbody>**，用 DocumentFragment 批量构建 <tr>，每 500–1000 行 append 一次
• 禁用 innerHTML = str 拼接 HTML 字符串——XSS 风险高，且字符串解析开销大

每次插入后必须主动让出主线程

即使用了 DocumentFragment，一次性插入 5000 行仍会让页面假死。关键动作在“节奏”：


Wechat HTML Publisher
直接上传HTML富文本到微信公众号草稿箱。支持完整的HTML格式,无需Markdown转换。
下载

立即学习“前端免费学习笔记（深入）”；

• 每批插入后加 await new Promise(r => setTimeout(r, 0))，触发微任务队列清空，交还控制权
• 不用 requestIdleCallback —— 它在低负载时才执行，滚动中可能被跳过；setTimeout(..., 0) 更可控
• 滚动监听需节流（throttle），避免高频触发导致插入任务堆积
• 禁用“无限滚动”式加载表格：它破坏浏览器前进/后退，且分页控件失去意义

超过 200 行就该启用纯虚拟滚动

当行数稳定超 200，<table> 的语义优势已让位于性能代价。此时应放弃真实 <tr><td>，改用块级容器模拟：

• 容器设 display: block; overflow-y: auto; height: 600px，行高必须固定（如 height: 42px）
• 只渲染可视区域 ±20 行，DOM 节点数严格锁定在 60 个以内
• <thead> 和 <tbody> 分层不可省：没 <thead>，表头无法提升为合成层，滚动时整表重绘
• 滚动时仅替换 textContent 和 dataset，不重建 DOM 节点

最容易被忽略的是：虚拟滚动不是“渲染更少”，而是“不让浏览器算布局”。一旦你写了 table-layout: auto 或漏了 <col>，哪怕只渲染 20 行，滚动时照样卡顿——因为浏览器每帧都在重排整个表格结构。