table-layout: fixed 必须配合显式列宽声明才生效，否则浏览器仍遍历内容计算列宽；虚拟滚动是应对大数据量表格的唯一有效方案，需预设行高并使用成熟库；html嵌套超4层会显著拖慢首屏渲染。
table-layout: fixed 必须配 <col> 才生效
只写 table-layout: fixed 没用。浏览器仍会遍历所有 <td> 内容算列宽，DOM 构建阶段就卡住。必须配合 <code><col> 显式声明宽度，例如：<col width="120">
<col width="auto">
<col width="80px">。
注意：width="auto" 是合法值，但仅限一列使用；多列设 auto 会让 fixed 行为退化回 auto。别在 <th> 或 <code><td> 上用 <code>width 属性或 style.width——它不参与列宽计算，纯属冗余。
常见翻车点：
- SSR 渲染后动态插入
<col>，但样式已计算完毕，无效 - 响应式场景下用 JS 改
<col width>，触发同步重排 - 忘记给第一行
<tr> 加 <code><th> 或 <code><td>，导致浏览器 fallback 到 auto 模式<h3>虚拟滚动比前端分页更扛数据量</h3> <p>当行数超过 200，单纯靠 <code>display: block+overflow-y: auto没用——DOM 还在那儿，浏览器照样解析、布局、绘制。真正有效的只有虚拟滚动：只渲染视口内 ±1～2 屏的数据行，其余用占位<tr> 填充高度。<p>关键约束条件：</p> <ul> <li>必须预设每行高度（或缓存动态高度），否则无法精确计算滚动偏移</li> <li>别手写滚动监听+重渲染，用 <code>virtuoso（Vanilla/TS）或react-window（React），它们已处理好IntersectionObserver回退、键盘导航和焦点管理 - 禁用
will-change: transform在滚动容器上——现代浏览器对表格内部元素做该声明反而触发强制图层提升，增加内存开销
嵌套超 4 层直接拖慢首屏渲染
HTML 嵌套深度超过 4 层，浏览器流式解析时每层都增加 DOM 创建、样式继承回溯和布局上下文生成开销，getComputedStyle 耗时非线性上升，移动端 FCP 延迟肉眼可感。
表格里最常踩坑的是：
- 在
<td> 里再套 <code><div><span><strong>内容</strong></span></div>——这会触发额外重排，抵消table-layout: fixed收益 - 用多层
<div class="cell-wrapper">...</div>包裹单元格内容，而非直接写文本或语义化内联标签 - SSR 模板注入的冗余包裹，如
<tbody><tr><td><div class="data-cell"><div class="inner"><span>xxx</span></div></div></td></tr></tbody> - 传
page=3&size=50，返回仅含这 50 条的 JSON，附带total字段 - 前端拿到数据后，立刻清空
tbody并批量插入——别用循环 +appendChild；用DocumentFragment或innerHTML一次写入（注意 XSS 风险，需 sanitize） - 禁用「无限滚动」式分页加载表格——它让分页控件失效、无法跳页、破坏浏览器前进/后退，且用户无法预估总数据量
实操建议：检查 Chrome DevTools → Elements 面板右键节点 → Show DOM properties，确认 depth ≤ 4；把首屏关键表格内容直接放在 <tbody> 下一级，最多嵌套 2 层。<h3>服务端分页不能靠前端切片模拟</h3>
<p>前端 <code>data.slice(page * size, (page + 1) * size) 对 1 万行以内尚可，但数据一过 5 万，JS 解析 JSON + 数组切片就成瓶颈，且用户无法跳转到末页。
真实分页必须由后端支持：
首次加载建议默认取 size=20，而非 size=100；大尺寸分页看似“少翻页”，实则首屏渲染压力陡增，CLS（累计布局偏移）极易超标。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
