html表格性能瓶颈源于dom节点爆炸、渲染阻塞和无节制js操作；应采用虚拟滚动、服务端分页、table-layout:fixed配宽度、懒加载优化及状态管理前置优化。
HTML 表格本身不慢，慢的是你一次性塞进去几千行 <tr> 还配着复杂样式、内联脚本和未压缩的数据。核心问题从来不是 <code><table> 标签，而是 DOM 节点爆炸 + 渲染阻塞 + 无节制的 JS 操作。<h3>虚拟滚动比“优化CSS”管用十倍</h3>
<p>当表格行数超过 200，<code>display: block 或 overflow-y: auto 加固定高度根本没用——DOM 还在那儿，浏览器照样解析、布局、绘制。真正有效的只有虚拟滚动：只渲染视口内 ±1～2 屏的数据行，其余用占位 <tr> 填充高度。<ul>
<li>必须预设每行高度（或使用动态高度缓存），否则无法精确计算滚动偏移</li>
<li>不要自己手写滚动监听+重渲染，用成熟库如 <code>react-window（React）或 virtuoso（Vanilla/TS），它们已处理好 IntersectionObserver 回退、键盘导航、焦点管理
will-change: transform 在滚动容器上——现代浏览器对表格内部元素做该声明反而触发强制图层提升，增加内存开销.map() 渲染；先按当前 offset + pageSize 切片，再生成 DOM分页加载要配合服务端，不能只靠前端切片
前端分页（如 data.slice(page * size, (page + 1) * size)）对 1 万行以内尚可，但数据一过 5 万，JS 解析 JSON + 数组切片就成瓶颈，且用户无法跳转到末页。
- 真实分页必须由后端支持：传
page=3&size=50，返回仅含这 50 条的 JSON，附带total字段 - 前端拿到数据后，**立刻清空 tbody 并批量插入**，别用循环 +
appendChild；用DocumentFragment或innerHTML一次写入（注意 XSS 风险，需 sanitize） - 禁用「无限滚动」式分页加载表格——它让分页控件失效、无法跳页、破坏浏览器前进/后退，且用户无法预估总数据量
- 首次加载建议默认取
size=20，而非size=100；大尺寸分页看似“少翻页”，实则首屏渲染压力陡增，CLS（累计布局偏移）极易超标
table-layout: fixed 必须配 <col> 宽度声明
只写 table-layout: fixed 不生效。浏览器仍会遍历所有单元格内容来算列宽，DOM 构建阶段就卡住。
- 必须显式给
<col>设置width，例如：<col width="120"><col width="auto"><col width="80px">
-
width="auto"是合法值，表示该列由内容撑开，但仅限一列；多列 auto 会让 fixed 失效 - 避免在
<th> 或 <code><td> 上用 <code>width属性或style.width——它不参与 table-layout 计算，纯属冗余 - 若列宽需响应式，用 CSS
@media控制<col>的width，而非 JS 动态改 style - 表格内图片一律不用
loading="lazy"，改用 IntersectionObserver 手动控制：监听<tr> 进入视口，再用 <code>src替换data-src - 复杂单元格（如带图表、富文本编辑器）必须做成异步组件：用
import()动态导入，配合placeholder占位，避免阻塞整行渲染 - 禁止在
<td> 内直接写 <code><script></script>或onclick行内事件——它们会随每一行重复解析执行，1000 行就是 1000 次 parse最常被忽略的一点：表格性能瓶颈往往不在渲染，而在数据落地前——比如未节流的搜索输入导致高频接口请求、未缓存的排序函数反复执行、或把整个原始数据集挂在 React state 里引发全表重渲染。优化得从网络层和状态管理开始，而不是死磕 CSS。
