documentfragment 在百万级节点动态更新中无法直接使用，因其内存占用和js执行模型无法承受；需分帧、虚拟滚动、增量挂载，仅在每帧内用作批量组装工具。
直接说结论：DocumentFragment 在百万级节点动态更新中**无法直接使用**，它不是为这种量级设计的——不是性能不够，而是内存和 JS 执行模型根本撑不住。真要处理百万节点，得先降维：分帧、虚拟滚动、增量挂载，DocumentFragment 只能在每帧内部起作用。
为什么百万节点不能一股脑塞进 DocumentFragment
DocumentFragment 确实不触发重排，但它仍需在内存中完整持有所有节点引用。百万个 document.createElement('div') 节点，每个都带属性、样式树占位、事件监听器入口（哪怕没绑），JS 引擎堆内存会瞬间飙升到数百 MB，V8 GC 压力剧增，主线程卡死在创建阶段，根本等不到“插入”那一步。
- Chrome 实测：50 万
div节点在DocumentFragment中创建耗时 >2s，内存峰值超 600MB，页面无响应 -
DocumentFragment插入后自动清空，但创建过程中的节点对象仍需 GC 回收——而百万级对象让 GC 成为瓶颈本身 - 它不支持
querySelector，但开发者常误写frag.querySelector('button')，结果返回null却没报错，后续逻辑静默失败
百万节点更新的正确分层策略
把“百万节点”拆成可调度的单元，DocumentFragment 只负责其中一帧的批量组装：
- 用
requestAnimationFrame切帧：每帧最多处理 200–500 个节点，避免单次 JS 执行超 16ms - 每帧内用
const frag = document.createDocumentFragment()组装这批节点，再container.appendChild(frag) - 跳过不可见区域：结合
IntersectionObserver或滚动位置，只挂载视口附近 ±2 屏的数据 - 复用节点：用
document.createElement+textContent替代 innerHTML，但对重复结构（如列表项）优先用template.content.cloneNode(true)，避免反复创建
table 场景下 fragment 的致命陷阱
百万行表格不是加个 DocumentFragment 就能提速的。浏览器对 table 元素有特殊解析规则，直接把 tr 塞进 DocumentFragment 再 append 到 table，会导致：
- 静默修正结构：浏览器自动把
tr包进tbody，但若原table没tbody，就触发一次隐式 DOM 重建 - 样式重算放大：每个
tr插入都会重新计算整行高度、边框合并、跨列逻辑 - 正确做法是：fragment 只组装
tr，插入目标必须是已存在的tbody元素，且该tbody需提前声明（不能靠浏览器自动生成）
容易被忽略的“非渲染”开销
很多人测出 fragment 加速，是因为只关注 layout 时间，却漏掉了三类隐形成本：
- 事件监听器注册：哪怕没显式调用
addEventListener，只要节点被创建，V8 就为其预留监听器槽位，百万节点 ≈ 百万槽位内存 - dataset 和 attribute 写入：每次
node.dataset.id = 'xxx'都触发内部哈希表扩容，高频写入比文本内容更耗时 - DOM 引用链：fragment 子节点仍持有
parentNode指向 fragment，而 fragment 持有ownerDocument的弱引用——这在 V8 中影响 GC 标记效率
真正要跑通百万节点，DocumentFragment 只是工具链里的一环，不是银弹。它解决不了数据建模、内存生命周期或渲染管线调度的问题，这些得靠架构层面的取舍。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
