直接渲染万行表格卡死的根源是DOM节点爆炸与table-layout:auto导致的强制重排。需用table-layout:fixed配合<col>预设列宽，服务端分页替代前端切片，并采用虚拟滚动方案。
HTML <table> 标签本身不慢，慢的是你一次性塞进几千行 <tr> 还带着内联样式、未压缩 JSON、重复事件监听和无节制的 JS 操作。真实瓶颈从来不是标签语义，而是 DOM 节点爆炸 + 渲染阻塞 + 缺乏数据切片控制。
为什么直接渲染万行表格会卡死？
浏览器解析 HTML 时，每条 <tr> 都是独立 DOM 节点；1 万行 ≈ 10 万个节点（含 <td>），触发重排重绘频率陡增，主线程长时间被占满。更糟的是：若用了 table-layout: auto（默认），浏览器必须遍历所有单元格内容算列宽，DOM 构建阶段就卡住——哪怕数据已加载完，表格仍“白屏”数秒。
- 常见错误现象：
DOMContentLoaded已触发，但tbody内容迟迟不出现；滚动卡顿、FPS掉到 10 以下；内存占用飙升至 500MB+ - 性能影响：首屏时间（FCP）超 3s，CLS（累计布局偏移）极易超标，尤其当列宽未预设、字体未加载完成时
- 兼容性注意：Safari 对大量
<tr>的 layout 计算比 Chrome 更慢，iOS WebKit 下卡顿更明显
table-layout: fixed 必须配 <col> 才生效
只写 table-layout: fixed 是无效的。浏览器仍会扫描全部单元格内容来推导列宽，<col> 才是真正参与布局计算的唯一合法方式。
-
<col width="120"><col width="auto"><col width="80px">—— 其中width="auto"合法，但仅限一列；多列设auto会让fixed失效 - 禁用在
<th>或<td>上写width属性或style.width：它们不参与 table 布局，纯属冗余且干扰调试 - 响应式列宽？用
@media控制<col>的width，别用 JS 动态改style—— 后者会强制重排
分块加载必须服务端配合，前端切片只是障眼法
前端 data.slice(page * size, (page + 1) * size) 对 5 万行以上数据毫无意义：JSON 解析 + 数组切片本身就成了瓶颈，且用户无法跳转末页。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
- 真实分页要求后端支持
page=3&size=50，返回仅含这 50 条的 JSON，并附带total字段 - 前端拿到数据后，**立刻清空
tbody并批量插入**：用DocumentFragment或innerHTML一次写入（注意 XSS，需 sanitize） - 禁用「无限滚动」式加载表格：它破坏浏览器前进/后退，让分页控件失效，且用户无法预估总数据量
- 首次加载建议
size=20，而非size=100—— 大尺寸分页看似省翻页，实则首屏渲染压力陡增，CLS 容易超标
虚拟滚动是唯一能撑住 10 万+ 行的方案
当表格行数超过 200，display: block + overflow-y: auto 加固定高度根本没用——DOM 还在那儿，浏览器照样解析、布局、绘制。真正有效的只有虚拟滚动。
- 必须预设每行高度（如
48px），或使用动态高度缓存（如react-window的VariableSizeList）；否则无法精确计算滚动偏移 - 不要自己手写滚动监听 + 重渲染：用成熟库如
react-window（React）、virtuoso（Vanilla/TS），它们已处理好IntersectionObserver回退、键盘导航、焦点管理 - 禁用
will-change: transform在滚动容器上——现代浏览器对表格内部元素做该声明反而触发强制图层提升，增加内存开销 - 后端返回原始数组？前端别直接
.map()渲染；先按当前offset+pageSize切片，再生成 DOM
最常被忽略的点：虚拟滚动依赖可预测的行高，而实际业务中常有“自动换行”“图片异步加载”“字体未就绪”导致行高浮动——这时必须用 resize-observer 或 font-load 等机制兜底，否则滚动错位、空白行、内容撕裂全都会出现。
