dom节点数超5万易触发内存警戒线，关键在活跃节点数、结构深度与渲染策略；需分片异步插入、预留缓冲区、扁平化嵌套并复用元素实例。
DOM节点数超过5万就容易触发内存警戒线
Chrome中performance.memory.usedJSHeapSize在节点数达5万左右常突破85%阈值，尤其当每个节点带dataset、addEventListener或内联样式时。这不是硬性上限，但和设备内存强相关：16GB内存机器可撑到8万，而8GB笔记本在4万就可能卡死。关键不是“总节点数”，而是“同时存在于DOM树中的活跃节点”——动态插入后不移除、不remove()、不置空innerHTML，就会持续累积。
用DocumentFragment批量插入仍不够，得配合分片节流
单纯用DocumentFragment只解决单次插入的重排开销，不缓解主线程阻塞。真正有效的是把数据切片 + 异步调度：
- 每批控制在200–500个节点（实测平衡点），太少导致调度开销占比高，太多仍会卡顿
- 用
requestIdleCallback比setTimeout更稳，但它不保证执行时机；若需确定性，改用requestAnimationFrame+ 计数器，在每次重绘前最多处理N个 - 切片不能简单按数组下标均分，要检查是否跨语义块——比如
<tr>必须整行插入，不能把一个<code><tr>拆成两段 <h3>虚拟滚动里最容易被忽略的缓冲区陷阱</h3> <p>只渲染可视区域看似省内存，但滚动快时会出现白屏或跳帧，本质是“缓冲区不足”。真实项目中必须预留前后至少10行（或3倍视口高度）的额外节点：</p> <ul> <li>缓冲区太小 → 快速滑动时来不及创建新节点，用户看到空白</li> <li>缓冲区太大 → 节点数回升，内存占用逼近原始全量渲染水平</li> <li>别复用<code>innerHTML字符串模板来“重绘”节点，每次赋值都触发完整解析；应复用Element实例，仅更新textContent和dataset.index
DOM深度每+1，内存与布局成本非线性上升
一个含5层嵌套的<div>结构，其内存占用和样式计算耗时远高于5个同级<code><div>。浏览器为每个父节点维护继承链、布局上下文、CSSOM引用，深度越深，这些元数据膨胀越快。常见冗余模式：
<ul>
<li>
<code><div class="wrapper"><div class="inner"><div class="content">…</div></div></div> → 改用display: grid + grid-template-areas
<div> → 改用<code><span></span> + flex布局，或直接<svg></svg>内嵌<text></text>
<input>外硬套<div><div><div> → 用<code><label></label>包裹并靠CSS控制间距
扁平化不是删标签，是把视觉层级交给CSS承担；验证效果看Chrome DevTools Elements面板右键节点的“Show DOM properties”，重点盯layoutObject和computedStyle引用数——降下来才算真生效。
