直接 innerhtml 赋值后必须立刻调用 normalize()，因为浏览器解析 html 时保留所有空白文本节点，导致相邻 text 节点冗余、textcontent 失真；normalize() 可合并相邻文本节点并移除空节点，但仅作用于 dom 节点而非字符串。
为什么直接 innerHTML 赋值后必须立刻调用 normalize()
富文本编辑器（如 contenteditable 区域）在用户回车、粘贴、撤销时，会生成大量相邻的 Text 节点，其中夹杂换行符、缩进空格甚至纯空字符串（nodeValue === ''）。这些节点不渲染，但会干扰 childNodes.length、破坏 textContent 提取精度、让遍历逻辑出错。
element.innerHTML = htmlString 不会自动合并或删除它们——浏览器只按 HTML 解析规则建树，保留所有空白文本节点。此时必须手动触发结构优化：
-
element.normalize()会立即合并相邻Text节点，并移除空节点 - 它不修改非文本节点（如
<div>）、不触发表单控件值、也不影响事件绑定 <li>调用后 <code>element.childNodes.length通常显著减少，element.textContent更贴近“人眼所见”结果 - 正确做法：先用
template.innerHTML = htmlString转成 DOM，再对template.content调用normalize()，最后读取template.innerHTML - 推荐用
DocumentFragment或template，避免污染主文档 - 不要对未插入 DOM 的元素提前调用：
const el = document.createElement('div'); el.normalize();—— 此时无子节点，什么也不会发生 - 不要对
Text节点本身调用：textNode.normalize()合法但无意义；该方法只在其父节点上起作用 - 用
new DOMParser().parseFromString(html, 'text/html')创建无执行上下文的文档，避免脚本执行 - 遍历其
body子节点，只保留白名单标签（p、strong、ul/li等），删掉style、class、on*属性 - 对解析后的
document.body或其克隆节点调用normalize()，清理残留空文本节点 - Safari 可能返回空字符串，需 fallback 到
getData('text/plain')，并做.replace(/\u200b/g, '')清零宽字符 -
<p>hello</p> <p>world</p>中间被<div> 隔开 → 两边文本不会合并 <li> <code><div><p>text</p></div>缺失闭合标签 → 不会自动补全 -
<table> <tr><td>cell</td></tr> 少一个 <code>→ 不会修复嵌套 - 冗余
<font></font>、<center></center>标签 → 不会删，得靠strip_tags或白名单过滤
normalize() 对原始 HTML 字符串无效，必须作用于 DOM 节点
常见错误是把 normalize() 当成字符串处理函数：比如对从编辑器取出来的 innerHTML 字符串直接调用，这完全没效果。
它只能作用于已挂载或已创建的 DOM 节点对象（包括 DocumentFragment 或 template.content）：
如何配合 DOMParser 清洗粘贴内容并安全调用 normalize()
粘贴时拦截 paste 事件，比事后清洗更可靠——能阻止含 XSS 风险的 HTML 直接进 DOM。关键路径是：preventDefault() → 读取 clipboardData.getData('text/html') → DOMParser.parseFromString() → 过滤 → normalize() → 插入。
别指望 normalize() 解决所有结构问题，它不修复嵌套错误
normalize() 只处理 Text 类型子节点：合并相邻文本、移除空节点。它不会跨过元素节点合并文本，也不处理 Comment 节点，更不修正 HTML 结构错误。
比如这些情况它完全不管：
真正复杂的结构修复，得靠 DOMParser + 白名单遍历，或服务端用 lxml 的 recover=True 和 Cleaner 组合处理——normalize() 只是干净链条里最轻量、但最容易被跳过的那一步。
