table-layout: fixed 不生效是因为它只跳过扫描，真正决定列宽的是 col 元素；必须用 width 属性（如 width="120"）定义列宽，且 auto 仅限一列，禁用 style.width 和 class 控制。
table-layout: fixed 不生效，列宽还是乱的
不是 CSS 没写对，而是 table-layout: fixed 本身不带宽度定义能力——它只负责“跳过扫描”，真正决定列宽的是 <col> 元素。只加样式不加 <col>，浏览器仍会 fallback 到 auto 模式逐行计算。
实操建议：
- 必须在
<table> 内、<code><thead> 前插入 <code><col>，例如：<col width="120"> <col width="80"> <col width="auto"> -
width="auto"只能用在**至多一列**，多列设 auto 会让 fixed 失效 - 禁用
<td width="..."> 和 <code>style.width，它们不参与布局计算，反而干扰<col>推导 - Safari 对
<col>解析更严格，务必用属性写法（width="120"），别用 CSS 类控制 - 改用
DocumentFragment批量构建：每 500–1000 行 append 一次，中间加await new Promise(r => setTimeout(r, 0))让出主线程 - 服务端返回 JSON，而非 HTML 字符串；前端按节奏渲染，而非全量拼接
- 首次加载分页 size 控制在 20–50，避免首屏渲染压力过大导致 CLS 超标
innerHTML 插入万行表格后页面假死
问题不在 JS 执行慢，而在 DOM 构建阶段主线程被锁死：6 万行 <tr> 字符串解析 + 节点创建 + 重排重绘，连续占用超 30 秒。
<p>实操建议：</p>
<ul>
<li>绝对禁用 <code>element.innerHTML = hugeString 或 jQuery 的 .html()
滚动卡顿、FPS 掉到 10 以下
不是数据太多，而是你让浏览器把所有 <tr> 都当成“需要实时参与渲染”的节点对待。滚动时反复触发重排，尤其在高 DPR 大屏上，内存分配不均 + GC 延迟直接掉帧。
<p>实操建议：</p>
<ul><li>必须拆出 <code><thead> 和 <code><tbody> —— 没 <code><tbody>，滚动时整个表格重绘，GPU 层面浪费严重
<li>虚拟滚动是唯一撑住 10 万+ 行的方案：固定行高（如 <code>48px）、撑高容器用 phantomHeight、缓冲区至少 Math.ceil(viewportHeight / rowHeight) + 2
requestAnimationFrame 节流，禁用直接写 onscroll；避免在滚动中调用 getBoundingClientRect() 或 offsetTop，它们强制同步 layoutMap 缓存，key 是 dataset.id，不是数组索引——错位会导致第 5 行数据显示在第 3 行位置为什么 Performance 面板里看不到真实瓶颈
红色长条（Long Task）只暴露 >50ms 的单次任务，但很多卡顿来自隐式同步 layout：比如读取 offsetTop 紧挨着修改 style.left，看似两行 JS 很快，却让后续 10 帧排队等待。
实操建议：
- 用
PerformanceObserver监听longtask、largest-contentful-paint、first-input，别轮询performance.getEntriesByType - 火焰图里若
Layout或Recalculate Style占比高，说明重排是主因，不是 JS 慢 - 在可疑操作前后打
performance.mark()，再查调度延迟，比console.time()更准 - Chrome 启动加
--enable-precise-memory-info，看usedJSHeapSize是否频繁逼近上限——GC 压力大时，哪怕代码没 leak，也会卡
<col>、<tbody> 分离、<code>requestAnimationFrame 节流、Map 键控复用——这些不是可选项，是大数据量表格能跑起来的硬性条件。漏掉任意一条，性能就不是“慢一点”，而是“彻底不可用”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
