文档碎片在静态列表初始化等场景比虚拟dom更轻量高效，但不适用于动态更新或滚动优化；虚拟滚动才是长列表性能关键，且常与文档碎片组合使用。
虚拟DOM不是万能的，文档碎片在简单批量插入时更轻量
如果你只是往一个空容器里一次性塞几千个 li，用 document.createDocumentFragment() 比 React 或 Vue 的虚拟 DOM 更快、内存更低。虚拟 DOM 要走创建 vnode → diff → patch 三步，而文档碎片直接跳过抽象层，只做一次真实 DOM 插入。
常见错误是误以为“用了框架就不用管 DOM 性能”，结果在初始化长列表时仍卡顿——框架内部未必自动用 fragment，尤其当组件没做批量优化或 v-for / map 直接返回节点时，仍可能逐个 appendChild。
- 适用场景：静态列表初始化、服务端渲染后客户端补全、无交互纯展示
- 不适用场景：需要响应式更新、频繁增删项、带复杂事件绑定的动态列表
- 性能差异实测（10,000 条）：
fragment首次插入耗时约 8–12ms；同等数据下 React 渲染耗时约 35–50ms（含 hydration 开销）
文档碎片不能解决滚动卡顿，虚拟滚动才是长列表的刚需
文档碎片只优化“插入一次”的成本，但对滚动时持续重排毫无帮助。当列表有 10 万条，哪怕只用 fragment 插入，滚动时浏览器仍要 layout 所有 10 万节点——scrollTop 读取、offsetHeight 计算、样式回流全在线上发生。
真正有效的解法是虚拟滚动：只保留可视区域 ± 缓冲区的几十个节点，其余用 transform: translateY() 定位 + 占位撑高。这和 fragment 完全不冲突，反而常组合使用——用 fragment 批量渲染那几十个可见项。
- 滚动容器必须设固定高度 +
overflow-y: auto，否则scrollTop不可靠 - 别用
Array.prototype.findIndex查可视起始索引，10 万数据线性遍历会卡死主线程；改用前缀和数组 + 二分查找 - 所有列表项统一用
position: absolute，禁用margin-top累加——后者每帧触发重排，前者走合成层
innerHTML 和 fragment 的选择取决于你是否需要保留节点状态
如果列表项里有 <input>、<select></select>、已绑定的事件监听器，或自定义 dataset，用 innerHTML 会清空所有这些状态；fragment 则能原样保留。
很多人图快写 container.innerHTML = items.map(...).join('')，结果发现输入框失焦、按钮点击失效、data-id 丢失——这不是 bug，是 innerHTML 的语义决定的：它销毁旧子树、重建新树。
- 用 fragment：已有现成节点（比如从模板克隆）、需绑定不同事件、内容来自用户输入（
textContent+ fragment 天然防 XSS） - 用 innerHTML：纯静态文本、无交互、追求极致插入速度且不关心节点复用
- 注意：IE9+ 兼容
appendChild+ fragment，但append()方法 IE10+ 才支持
虚拟DOM框架里手动用 fragment 反而可能破坏调度逻辑
React、Vue 等框架的更新机制依赖自身调度器（如 React 的 Fiber、Vue 的 reactivity system）。你在组件内手动调用 document.createDocumentFragment() 并直接操作真实 DOM，会绕过框架的 diff 和生命周期管理，导致 state 与视图不一致、ref 失效、useEffect / mounted 钩子错过时机。
正确做法是让框架控制渲染，你只优化框架内的写法：比如 Vue 中用 v-memo 配合 v-for，React 中用 memo + key 稳定、或改用 react-window 这类专为虚拟滚动设计的库。
- 不要在 useEffect / mounted 里手动建 fragment 插入大量节点——框架不知道你干了啥
- 框架组件内若需高频局部更新（如实时日志流），优先用 keyed 列表 + shouldComponentUpdate / memo，而非脱离框架 DOM 操作
- 真要手操 DOM，确保只作用于框架未接管的区域（如 canvas、第三方图表容器）
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
