document.createElement 高频调用会卡死，因其同步触发内存分配、样式挂载、layout 计算与 paint 准备；光标移动等场景下单帧新建/销毁数十节点将占满主线程 layout。
为什么 document.createElement 会突然卡死
高频创建 DOM 节点不是“写法问题”，而是触发了浏览器渲染管线的硬性瓶颈：每次 document.createElement 都会同步走完内存分配 → 样式挂载 → layout 计算 → paint 准备。在光标移动、语法高亮、协作光标叠加等场景下，单帧内新建/销毁几十个节点，主线程直接被 layout 占满。
常见错误现象包括：编辑器输入延迟明显、滚动卡顿、光标跳变、几小时后响应越来越慢。
- 残留引用是隐性杀手：用
removeChild()删除节点，但节点上绑着闭包监听器或通过dataset持有外部状态，就会形成内存泄漏 - IE11 / Edge Legacy 中
node.remove()不清理事件监听器，必须显式调用removeEventListener -
contenteditable容器内插入节点，会额外触发输入法状态重同步，放大 layout 开销 - 用
innerHTML =替换内容时，已有的oninput或委托事件会被静默丢弃
DocumentFragment 是底线，但不是银弹
DocumentFragment 能把多次 appendChild 合并成一次真实插入，避免反复重排。但它只解决“插入前”的离线操作，对插入后的样式计算、字体回退、文本布局无影响。
容易被忽略的细节：
立即学习“前端免费学习笔记（深入）”；
- fragment 插入后自动清空，不能复用——每次更新都得重新调用
document.createDocumentFragment() - 它不支持
querySelector，也不能直接绑定事件；想查子节点得先插入再查，破坏离线性 - 若 fragment 内含
textarea或input，插入瞬间会触发 focus/selection 同步，导致光标跳变 - 仅推荐用于「纯展示型」节点（如高亮色块、只读标签），交互型控件（可编辑单元格、折叠按钮）应走复用池
DOM 复用池必须配合“结构冻结”
复用池不是缓存节点对象，而是缓存「可复位的 DOM 结构模板」。关键在 recover() 时的清理粒度是否彻底：
- 必须清空
textContent和innerHTML，否则上次残留内容会在下次create()后意外显示 - 必须重置所有
dataset字段（如node.dataset.line、node.dataset.tokenType），不能只删部分 - 必须手动移除所有事件监听器（哪怕用的是事件委托，也要检查是否还挂在父容器上）
- 涉及
getBoundingClientRect()或offsetTop的节点，需确保父级 layout 状态稳定，否则复用后尺寸错乱
高亮与光标必须分层隔离更新
语法高亮、选区背景、协作光标、行号、折行标记……这些视觉层如果混在同一个 DOM 节点树里更新，每次改动都会触发整行甚至整屏的 layout 重算。
实操建议：
- 用
transform和opacity控制高亮层和光标层，它们走合成层（Composite），不触发 layout - 把高亮逻辑从「逐字符生成 span」改为「按 token 区间批量绘制 canvas 或绝对定位 div」
- 协作光标用
position: fixed+pointer-events: none，脱离文档流，避免干扰主内容 layout - 行号列单独抽成一个
<div class="gutter">，用 <code>will-change: transform提示浏览器提前升层最复杂的不是怎么画出来，而是怎么让它们互不干扰地更新——结构上分层、样式上隔离、更新时异步节流，三者缺一不可。
