富文本编辑器出现文本节点碎片，是因为用户粘贴、撤销重做或动态插入内容时，浏览器在标签间、换行处生成大量空白Text节点；调用element.normalize()可合并相邻文本节点并删除空节点，但须在DOM变更后立即作用于直接受影响的容器元素，不可滥用document.normalize()，且不能替代编辑器内部的结构校验逻辑。
为什么富文本编辑器里会出现文本节点碎片
用户粘贴、撤销重做、动态插入内容时，编辑器常会反复调用 appendChild() 或 insertBefore() 创建多个 Text 节点，比如连续输入两次空格、回车后又打字，或从 Word 复制一段含格式的文本——浏览器解析时会在标签之间、换行符处生成大量空白 Text 节点。这些节点肉眼不可见，但会让 childNodes 长度暴增、textContent 与 innerHTML 行为不一致，甚至干扰光标定位和范围（Range）计算。
直接调用 element.normalize() 就够了吗
够，但必须选对时机和目标节点：
- 不要对整个
document调用document.normalize()—— 开销大，且可能误触未挂载的临时节点 - 应在每次 DOM 变更后，立即对**直接受影响的容器元素**调用，例如：
editorRoot.normalize()（editorRoot是 contenteditable 的根div） - 若编辑器使用虚拟 DOM 或自定义节点树（如 Slate、Lexical），
normalize()仅作用于真实 DOM 层，不能替代其内部的 normalize 逻辑；此时应优先走编辑器提供的 hook（如 Slate 的normalizeNode） - 注意：它不处理被
Comment或Element隔开的文本节点，只合并「相邻」的Text节点
normalize() 对编辑器输出 HTML 有实际影响吗
有，但仅限结构层面，不影响语义或样式：
- 调用后
innerHTML中的冗余空白不会减少——比如"a<span>b</span>c"中的 a 和 c 不会因 normalize 合并成一个文本节点，因为中间隔着span - 真正被合并的是纯文本插入场景：连续
createTextNode('Hello')+createTextNode(' ')+createTextNode('world')→ 合并为单个节点，nodeValue === "Hello world" - 它不会删除文本内的多余空格（如双空格、制表符），也不会修正
innerHTML解析出的嵌套错误（如孤立<li>）；这类问题得靠DOMParser预处理或白名单清洗 - 如果你依赖
childNodes遍历做格式识别（比如找连续加粗文本），必须在遍历前调用normalize()，否则可能漏匹配
容易被忽略的兼容性与副作用
normalize() 在所有现代浏览器中行为一致，但有两个隐性坑：
立即学习“前端免费学习笔记（深入）”；
- 它会改变
Text节点引用——原来指向第一个文本节点的Range或NodeIterator可能失效，编辑器若缓存了旧节点引用（比如用于光标恢复），需在normalize()后重新 resolve - 某些编辑器（如早期 Quill）在
innerHTML = html后不自动 normalize，导致后续通过 JS 插入的文本与原生解析文本混杂；这时得手动补一句editorRoot.normalize()，而不是指望浏览器自动收拾 - 它对
DocumentFragment也有效，但 Fragment 未挂载时调用无意义；务必等 fragment 已插入文档或已 assign 给编辑器容器后再调用
normalize()，而是调用的**粒度**和**时机**没对齐编辑器的数据流模型——尤其当编辑器自己维护一套节点状态时，DOM 层的 normalize 只是最后一道“保洁”，不该承担结构校验的主责。 
