表格性能瓶颈在于频繁removechild+createelement导致事件丢失、布局重算和内存抖动，应使用map缓存tr节点并复用结构，避免同步layout触发，配合intersectionobserver或滚动范围计算实现高效虚拟滚动。
大规模表格不池化节点，滚动一卡一卡的，不是JS慢，是DOM反复创建销毁拖垮渲染管线。
为什么表格场景下 removeChild + createElement 是性能毒药
每行 tr 都带事件监听、定时器、dataset 状态，removeChild 一调，这些全丢；再 createElement，又得重绑、重设、重计算布局。浏览器每帧滚动都触发几十次这种操作，layout 时间直接翻倍。
- 真实现象：
console.time('layout')测出来单次appendChild耗时从 0.3ms 涨到 8ms+ - 兼容陷阱：IE11 不支持
IntersectionObserver，但用getBoundingClientRect()+ scroll 监听，若没池化，每帧都 new 一堆tr，内存抖动更剧烈 - 表格结构特殊：
tbody内部不能随便innerHTML = ''，否则所有tr子节点事件全失，且table的 layout 触发比普通div更重
用 Map 缓存 tr 节点，靠 dataset.id 绑定数据身份
别用数组存 tr，索引错位会导致第 5 行数据显示在第 3 行位置——表格对顺序极其敏感。必须用 Map，以唯一 dataset.id（如 'row-12345'）为 key。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 缓存时机：行即将滚出视口时，只设
tr.style.display = 'none'，不removeChild，保事件、保结构 - 复用逻辑：新数据来，先
nodePool.get(id)，存在就tr.style.display = ''，再批量更新td文本、dataset.value、className - 关键约束：所有
tr初始化时必须写死子元素结构，比如固定 5 个td，class 名分别为.name、.status等，复用时只改内容，不增删td
domPoolFactory 做预分配池，但表格要微调回收逻辑
通用池工厂（如 domPoolFactory(() => document.createElement('tr'))）能省构造开销，但表格里不能简单 node.textContent = '' —— 会清掉所有 td，破坏结构。
- 回收前必须手动清空每个
td的文本和 class：tr.querySelectorAll('td').forEach(td => { td.textContent = ''; td.className = ''; }) - 禁止在
createFn里绑定事件，应在acquireNode后按需addEventListener，回收前用removeEventListener解绑 - 池大小建议 20–30：表格行高固定（如 42px），可视区最多显示 20 行，加 10 行缓冲刚好，再多空闲节点反而干扰 GC
滚动监听里别碰 offsetTop 或 getBoundingClientRect()
这两个 API 强制触发同步 layout，滚动中高频调用等于主动卡自己。尤其表格行数上万时，一次 getBoundingClientRect() 可能占掉 3–4ms 主线程。
- 替代方案：用
IntersectionObserver监听tr进出视口，它异步、轻量、不阻塞渲染 - 兜底兼容：老项目必须用 scroll 监听时，只对「当前正在滚动」的区域做判断，用
container.scrollTop和行高算出可见范围，再查 Map 里对应 id 的节点是否已缓存 - 容器必须设
height和overflow-y: auto，否则IntersectionObserver无法判定视口边界，scrollTop也读不到有效值
真正难的不是写池代码，而是让所有 tr 结构完全一致、所有事件绑定解绑路径可预测——一旦某处漏了 removeEventListener，池里节点复用几次后就会堆满重复监听器。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
