富文本编辑器dom树深碎是因粘贴word、撤销重做等操作在标签间生成大量空text节点；element.normalize()可合并相邻text节点并删除空节点，须在每次dom变更后立即作用于直接受影响容器（如editorroot），不可滥用document.normalize()，且调用后需重新resolve缓存的range引用。
为什么富文本编辑器输出的 DOM 树总是又深又碎
用户粘贴 Word、连续撤销重做、或用 document.execCommand 插入格式时，浏览器会在标签之间、换行处生成大量空 Text 节点；contenteditable 本身不合并节点，导致 childNodes 长度暴增、textContent 和 innerHTML 行为错位，甚至光标定位失效。
element.normalize() 是什么，什么时候该调用它
它会合并相邻的 Text 节点，并移除空节点（nodeValue.length === 0 的 Text），但只作用于「紧挨着」的文本节点，中间插了 Comment 或 Element 就不会合并。
- 必须在每次 DOM 变更后，立即对直接受影响的容器调用，比如：
editorRoot.normalize()（editorRoot是你的contenteditable根元素） - 不要调用
document.normalize()——开销大，且可能误操作未挂载的临时节点 - 若用 Slate/Lexical 等虚拟 DOM 编辑器，
normalize()只作用于真实 DOM 层，不能替代其内部normalizeNodehook - 调用后，原有
Text节点引用（如缓存的Range、NodeIterator）会失效，需重新 resolve
normalize() 对输出 HTML 有影响吗
有，但仅限结构层面：它不会减少 innerHTML 中的空白字符（比如 "a<span>b</span>c" 不会因 normalize 变成 "abc"），也不会修正嵌套错误或过滤非法标签。
使用HTML,CSS,JavaScript开发Android应用程序 英文文字pdf版附源文件
下载
如果你了解HTML，CSS和JavaScript，您已经拥有所需的工具开发Android应用程序。本动手本书展示了如何使用这些开源web标准设计和建造，可适应任何Android设备的应用程序 - 无需使用Java。您将学习如何创建一个在您选择的平台的Android友好的网络应用程序，然后转换与自由PhoneGap框架到一个原生的Android应用程序。了解为什么设备无关的移动应用是未来的潮流，并开始构建应用程序，提供更
- 真正被合并的是纯文本插入场景：连续
createTextNode('Hello')+createTextNode(' ')+createTextNode('world')→ 合并为单个节点，nodeValue === "Hello world" - 如果你依赖
childNodes遍历做格式识别（例如找连续加粗文本），必须在遍历前调用normalize()，否则可能漏匹配 - 它不处理文本内冗余空格（如双空格、制表符），这类清洗得靠
DOMParser预处理或白名单过滤
除了 normalize，还有哪些 DOM 结构优化动作必须同步做
单纯调用 normalize() 远不够。富文本输出要稳定可靠，还得配合以下动作：
- 在序列化前，先用递归 DFS 遍历生成 token 数组（
{text: "..."} / {markup: "<p>"}</p>），避免因碎片节点导致闭合标签位置错乱 - 对
innerHTML输出做最小化清洗：移除无意义的<font></font>、空span、重复style属性 - 若需兼容 WebView 渲染（尤其 Android
WebView.loadData()），确保所有img路径为绝对路径或 base64，且避免使用未支持的 CSS 属性（如contain） - 监听
input事件后延迟 1 帧再 normalize（用requestAnimationFrame），避免与浏览器默认行为冲突
碎片节点问题不是“调一次 normalize() 就万事大吉”，而是要嵌入编辑器变更生命周期里——时机不对、范围太大、后续没兜底，反而会让光标和选区更不稳定。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
