innerHTML一次性写入千行以上表格必然卡顿，因浏览器需同步解析字符串、创建节点并触发多次重排重绘；应改用DocumentFragment分批构建（每500–1000行一批），插入后通过await new Promise(r => setTimeout(r, 0))让出主线程以保持响应。
innerHTML 一次性写入千行以上表格，必然卡顿——这不是 JS 慢，是浏览器在解析和构建 DOM 阶段被压垮了。必须换用 DocumentFragment + 分批插入，且每批后让出主线程。
为什么 innerHTML 渲染大表格会假死
浏览器对 innerHTML 的处理是同步、不可中断的：它要先将整个字符串交给 HTML 解析器，再逐个生成节点、挂载到 DOM 树、触发重排重绘。6000 行 × 12 列的表格，光字符串解析和节点创建就能吃掉 300ms+ 主线程时间，用户操作完全无响应。
- 哪怕内容只是纯文本，
innerHTML = hugeString仍会触发多次 layout，不是“没样式就快” - jQuery 的
.html()或原生el.innerHTML在大数据量下内部有额外字符串拼接开销 - 服务端返回 HTML 字符串（而非 JSON），等于把渲染节奏完全交给了浏览器，失去控制权
用 DocumentFragment 分批构建真实可行
核心是把 DOM 构建从“一次全量”变成“小块可控”，每批控制在 500–1000 行，插入后主动让出主线程。
- 每次用
document.createElement('tr')+textContent插入单元格，比innerHTML更安全（防 XSS）、更轻量 - 用
DocumentFragment缓存一批tr，再一次性appendChild到tbody，避免反复触发 layout - 每批插入后加
await new Promise(r => setTimeout(r, 0))，确保滚动、输入等事件能及时响应 - 不要用
fragment.appendChild(tr)循环完再插——那和innerHTML差别不大；要每 batch 后tbody.appendChild(fragment)，再清空 fragment
table-layout: fixed 必须配合 <col> 才生效
只写 style="table-layout: fixed" 不够。浏览器在 fixed 模式下优先读 <col>，其次看第一行 th 的 width，td 上的 width 属性完全无效，还可能干扰编辑器尺寸测量。
立即学习“前端免费学习笔记（深入）”；
-
<col>必须放在<table> 开头、<code><thead> 之前，不能塞进 <code><thead> 或 <code><tbody> 里 <li>动态列数时，JS 插入数据前先批量生成并 <code>append<col>节点，例如：Array.from({length: colCount}, () => Object.assign(document.createElement('col'), {style: 'width: 120px'})).forEach(c => table.insertBefore(c, table.firstChild)) - 响应式场景下，用
@media控制<col>的width，比如小屏设width: 30%，但注意仅一列可设auto，否则fixed失效 - 所有
tr必须有明确height（如style="height: 36px"），不能依赖内容撑开 - 禁用
line-height单独撑高，它会导致文字垂直居中偏移，影响编辑框对齐 - 表头
thead和内容tbody要分离，thead固定定位，tbody滚动，否则合成层提升失效，滚动仍重绘整表 - 避免在
td里嵌套div或span，它们会触发额外重排，抵消fixed和虚拟滚动收益
虚拟滚动必须绑定固定行高
如果开启虚拟滚动但行高不固定，编辑器光标定位、方向键焦点移动、双击编辑区域都会错乱——因为浏览器无法准确映射 scrollTop 到逻辑行号。
最容易被忽略的是：<col> 的位置和数量必须与实际列严格一致——少一个，最后一列自动均分；多一个，多余列宽被忽略；错位插入，fixed 行为退化回 auto。调试时直接看 DevTools 的 Computed Styles，确认 table-layout 是 fixed，且 width 列值与 <col> 完全对应。
