HTML解析器不支持增量渲染，所有table标签必须完整解析后才构建DOM；遇到<table>即阻塞等待闭合标签，tbody动态插入仍触发全表重排，唯有table-layout:fixed配合<col>预设宽度、DocumentFragment批量插入及虚拟滚动可缓解性能瓶颈。
HTML解析器不支持增量渲染，所有table标签必须完整解析后才构建DOM
浏览器的HTML解析器是串行、阻塞式流程：Tokenizer切分Token → Tree Construction逐个挂载节点。遇到<table>标签时，它不会“渲染一半就停”，而是必须等整块<table></table>闭合后，才能确定列结构、跨行关系和最终布局。这意味着：哪怕你用innerHTML分批写入<tr>，只要没闭合</table>，解析器就卡在“等待结束标签”状态；一旦闭合，就会触发全表重排。
为什么appendChild往tbody里加行仍会卡顿
表面上看，tbody.appendChild(tr)只操作子节点，但浏览器内部仍要重新计算整个表格的layout tree——因为table布局依赖所有行的尺寸来统一分配列宽（尤其table-layout: auto时）。每加一行都可能让已渲染的列宽度跳变，引发同步reflow。
- 避免直接循环调用
appendChild，哪怕目标是tbody - 必须用
DocumentFragment或字符串拼接批量插入，且每次插入后让出主线程（如await new Promise(r => setTimeout(r, 0))） -
tbody.innerHTML += '<tr>...</tr>'看似方便，但每次赋值都会先清空再重建全部子节点，比append()更慢、更易丢状态（如input焦点、滚动位置）
table-layout: fixed不是可选项，是大数据量前提
默认table-layout: auto会让浏览器扫描所有td内容来决定列宽，数据越多，扫描越久。一旦开启table-layout: fixed，浏览器就只看第一行th或<col>的width，后续行完全跳过内容测量——这是性能拐点。
- 必须显式设置
<col width="120">或<th style="width: 120px">，仅用CSSwidth可能被忽略 - 如果列宽需响应式，用
width: 20%而非flex或minmax()，后者在fixed模式下无效 -
word-break: break-word要加在td上，否则长文本会撑破固定列宽
真·增量只能靠JS控制，不是HTML解析器的事
所谓“增量渲染table”，本质是JS层面对数据分片+定时调度+DOM复用，和HTML解析器无关。解析器永远是一次性吃完整块HTML，JS只是想办法不让它一次吃太多。
立即学习“前端免费学习笔记（深入）”；
- 分批加载：用
fetch带offset/limit参数分页拉数据，而不是一次性取完再切片 - 虚拟滚动：只维护一个固定数量的
tr节点池，滚动时用dataset.index映射真实数据下标，不新建也不销毁 - 别信“用
requestIdleCallback就能轻松撑万行”——它只是让JS任务排队，不能绕过浏览器对table的layout约束
最常被忽略的一点：即使用了table-layout: fixed和虚拟滚动，<tbody>里若存在未设height的<tr>，浏览器仍会为每个tr生成layout节点——内存占用和GC压力不会减少。真正省资源，得从DOM节点数量下手，不是从CSS下手。
