HTML表格性能瓶颈在于DOM膨胀与渲染阻塞，需通过table-layout:fixed配显式宽度、虚拟滚动、服务端分页、语义化结构及批量DOM操作来优化。
HTML表格本身不慢，慢的是你一次性塞进去几千行 <tr> 还配着复杂样式、内联脚本和未压缩的数据。优化核心不是“怎么让 <code><table> 更快”，而是控制 DOM 节点数量、切断渲染阻塞链、让浏览器能跳过无效计算。<h3>用 <code>table-layout: fixed 必须配 <col> 显式宽度
只写 table-layout: fixed 没用。浏览器仍会遍历所有 <td> 内容推算列宽，DOM 构建阶段就卡住。<ul><li>
<code><col> 必须写在 <table> 开头，紧挨着 <code><caption></caption> 或 <thead> 之前<li>至少一列要设具体值，比如 <code><col width="120">
<col width="auto">
<col width="80px">；多列 width="auto" 会让 fixed 失效
<th> 或 <code><td> 上用 <code>style.width 或 width 属性——它不参与 layout 计算，纯属冗余@media 控制 <col> 的 width，而不是 JS 动态改 style超过 200 行就别渲染全量 DOM，上虚拟滚动
display: block + overflow-y: auto 加固定高度只是“假装滚动”，<tr> 全在内存里，浏览器照样解析、布局、绘制。<ul>
<li>必须预设每行高度（如 42px），或用动态高度缓存（如 <code>virtuoso 的 itemHeightEstimate）
react-window（React）或 virtuoso（Vanilla/TS）已处理 IntersectionObserver 回退、键盘导航、焦点管理will-change: transform 在滚动容器上：现代浏览器对表格内部元素做该声明反而触发强制图层提升，增加内存开销.map() 渲染；先按当前 offset + pageSize 切片，再生成 DOM服务端分页不能省，前端切片撑不过 5 万行
前端 data.slice(page * size, (page + 1) * size) 对 1 万行以内尚可，但数据一过 5 万，JS 解析 JSON + 数组切片就成了瓶颈，且用户无法跳转到末页。
立即学习“前端免费学习笔记（深入）”；
- 真实分页必须由后端支持：传
page=3&size=50，返回仅含这 50 条的 JSON，附带total字段 - 前端拿到数据后，**立刻清空
<tbody> 并批量插入**，别用循环 + <code>appendChild；用DocumentFragment或innerHTML一次写入（注意 XSS 风险，需 sanitize） - 禁用「无限滚动」式分页加载表格——它让分页控件失效、无法跳页、破坏浏览器前进/后退，且用户无法预估总数据量
- 首次加载建议默认取
size=20，而非size=100；大尺寸分页看似“少翻页”，实则首屏渲染压力陡增，CLS（累计布局偏移）极易超标 -
<caption></caption>是表格唯一合法标题，影响可访问性 API 和打印行为，别用<h2></h2>代替 - 合并单元格（
colspan/rowspan）后若出现错位，大概率是隐式网格不完整——补<td style="display:none"></td>这类虚拟单元格比调 height 更可靠 - 避免在
<table> 上写内联样式或事件监听器；把交互逻辑抽离到 <code><thead> 的 <code><th> 上，减少事件委托层级<p>真正卡顿的从来不是 <code><table> 标签本身，而是你没切断 DOM 膨胀路径、没把计算压力推给服务端、也没让浏览器提前知道“这一列到底多宽”“这一行固定多高”。这些细节不处理，再多 CSS 优化都是隔靴搔痒。</table>
语义结构不光为 SEO，更是性能前置条件
没 <thead>、<code><tbody>、<code><tfoot> 的表格，JS 操作时得反复遍历所有 <code><tr> 判断类型；打印分页时表头也不会自动重复；屏幕阅读器也无法区分标题与数据。<ul><li><code><th> 不只是加粗居中，它带 <code>scope="col" 或 scope="row" 才能让排序、筛选逻辑精准绑定目标列
