element.normalize() 必须在编辑器根容器挂载后、DOM变更完成时调用才有效，否则会导致光标错位、Range失效；它只合并直系相邻文本节点、不越界、不删空格，但会改变节点引用，需重新获取。
element.normalize() 能直接合并相邻文本节点并删空节点，但必须用对地方、用对时机——否则光标错位、Range 失效、childNodes 遍历结果突变，编辑器就出 bug 了。
为什么 normalize() 在富文本编辑器里经常“没效果”
不是方法失效，而是调用位置错了：normalize() 只作用于已挂载的 DOM 节点，且只处理其直系子节点中的相邻 Text 节点。
- 对未插入文档的临时
div提前调用：const el = document.createElement('div'); el.normalize();→ 子节点为空，什么也不做 - 对
document全局调用：document.normalize();→ 开销大，还可能误触未挂载的 fragment 或 shadow root - 对
Text节点本身调用：textNode.normalize();→ 合法但无意义，该方法只在其父节点上生效 - 期望跨过
<span></span>合并两侧文本："a"<span>b</span>"c"→ 不会变成"ac"，normalize()不越界
应该在哪调用 normalize() 才安全有效
目标必须是编辑器 contenteditable 的根容器（比如 div#editor），且必须在 DOM 真实变更后立即执行。
- 用户粘贴后：监听
paste事件，在setTimeout(() => editorRoot.normalize(), 0)中调用（确保浏览器完成解析） - 撤销/重做后：在编辑器状态更新完成、DOM 已 patch 的回调里触发，例如 Slate 的
onOperation后或 Quill 的text-change事件末尾 - 动态插入文本节点后：比如
editorRoot.appendChild(document.createTextNode('x'))→ 紧接着调用editorRoot.normalize() - 避免在
input或keydown中高频调用：它会改变节点引用，频繁触发可能导致光标跳动
normalize() 对编辑器行为的实际影响有哪些
它不改语义、不删空格、不修 HTML 结构，但会直接影响节点遍历和 Range 定位逻辑。
-
childNodes.length通常减少 —— 原来 5 个碎片文本节点，可能合并为 1 个 -
textContent值不变，但nodeValue的归属对象变了：原来指向第 2 个文本节点的Range，调用后可能指向已被销毁的旧节点 → 编辑器若缓存了节点引用（如用于光标恢复），必须重新 resolve - 不会压缩文本内空格：
"a b"还是"a b"，想清理得额外用.replace(/\s+/g, ' ').trim() - 对
innerHTML输出无感：合并后innerHTML字符串照旧含换行缩进，它只优化 DOM 树结构，不改序列化结果
如果编辑器用了虚拟 DOM（如 Slate/Lexical），还要手动调 normalize() 吗
要，但只是补充，不能替代框架自身的 normalize 逻辑。
立即学习“前端免费学习笔记（深入）”；
- Slate 的
normalizeNodehook 是模型层校验，保证数据结构合规；element.normalize()是渲染层收尾，确保真实 DOM 干净 - Lexical 的
editor.update()后，可对编辑器容器 DOM 调用normalize()，防止因底层 diff 漏掉的碎片残留 - 若编辑器禁用了原生
contenteditable（如完全接管输入），那normalize()就没必要 —— 节点由你全权创建/销毁，可控性更高 - 注意：虚拟 DOM 更新后，真实 DOM 可能尚未同步，建议在
requestIdleCallback或queueMicrotask中调用，避开渲染阻塞
normalize() 对已有节点引用的破坏性 —— 它不是“整理”，而是“重构”。只要编辑器里存在任何基于 childNodes[i]、firstChild 或缓存的 Text 节点的操作，就必须在 normalize() 后重新获取或 resolve。 
