document.createdocumentfragment() 可批量插入 dom 节点以避免高频回流，但需避免在 fragment 上读布局、混用读写操作，且不能替代事件委托或虚拟滚动。
直接用 document.createDocumentFragment() 就能压住编辑器里高频 DOM 插入引发的回流风暴——但前提是别在 fragment 上读布局、别混着“写”和“读”、别误以为它能替代事件委托或虚拟滚动。
为什么编辑器里不加 fragment 就容易卡
HTML 编辑器常需实时解析文本、高亮关键词、插入 token 节点。如果每次生成一个 span 就直接 appendChild 到容器，浏览器会在每轮循环中：重新计算父容器尺寸、重排浮动/定位关系、触发样式计算队列 flush——100 个 token = 最多 100 次回流。哪怕父容器设了 display: none，部分浏览器仍会做轻量 layout 计算，优化失效。
常见错误现象：
-
for循环里反复调用editorContainer.appendChild(el) - 拼接完节点后立刻读
el.offsetHeight或getComputedStyle(el) - 用
innerHTML +=动态追加，导致整段 HTML 重复解析与重建
document.createDocumentFragment() 的正确初始化姿势
必须用 document.createDocumentFragment() 创建，不能写成 new DocumentFragment()（多数浏览器报错或返回空对象）。它没有 parentNode、不挂载、不渲染，所有操作纯内存级。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
实操建议：
- 在解析逻辑外层一次性创建：
const frag = document.createDocumentFragment(); - 循环中只对
frag做appendChild/append/prepend，不调用任何读取布局的 API - 不要给
frag绑定事件监听器——它没真实 DOM 生命周期，事件无法冒泡到它身上 - 插入后
frag自动清空，再次使用需重新create
编辑器场景下最容易踩的三个坑
不是 fragment 不好用，而是编辑器交互太“贪”：既要即时渲染、又要测尺寸、还要响应光标位置。一不留神就破功。
-
边建节点边读 offsetHeight：哪怕只是
console.log(el.offsetHeight)，也会强制 flush 渲染队列，让 fragment 失去离线优势 -
把 fragment 当作事件代理容器：比如
frag.addEventListener('click', handler)——无效，frag不参与事件流，得等它插入后在真实父容器上监听 -
误以为 fragment 能绕过样式计算：给节点设
el.style.width = '200px'没问题，但紧接着调用getComputedStyle(el).width就会触发同步 layout，哪怕 el 还在 fragment 里
和 innerHTML 比，fragment 真的更快吗
在编辑器这种需要精细控制节点结构、绑定 dataset、动态设置 class 的场景下，innerHTML 反而更慢也更危险：
- 字符串拼接易 XSS（除非你严格 sanitize），而 fragment 是原生 DOM 构造，天然免疫
-
innerHTML +=每次执行都会先清空再重建整个子树，DOM 树越深，开销越大 - 无法在插入前设置
el.dataset.tokenType或绑定临时状态，只能靠正则或 parser hack 补救 - 若编辑器支持撤销/重做，fragment 方便保留节点引用，
innerHTML会丢失所有 JS 层对象关联
真正该警惕的，是把 fragment 当万能解药——它只解决“批量插入”的回流问题，不解决光标定位抖动、语法树深度遍历慢、或 CSS 选择器爆炸式匹配带来的重绘压力。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
