domparser 解析 html 字符串时会自动解码实体：
用 DOMParser 解析 HTML 字符串时，特殊符号会自动解码
DOMParser 不是“转义工具”，而是标准 HTML 解析器。当你用 new DOMParser().parseFromString(htmlStr, 'text/html')，浏览器会按真实 HTML 规则解析：所有合法实体（如 、<code>&、©）都会被还原为对应字符（、<code>&、©），而不是保留原始字符串。
这意味着：你传入 "a ，解析后 <code>doc.body.textContent 得到的是 "a —— 实体已消失。这不是 bug，是规范行为。
- 只对符合 HTML5 实体语法的片段生效（
、<code>、<code> 都行；但 <code><t;或孤立的&会被忽略或报错） - 不处理非标准实体（比如自定义的
&myentity;），也不还原 JS 字符串中的转义（"a \u003c b"不受影响） - 如果目标是“提取原始未解码的 HTML 片段”，别用 DOMParser；它天生面向渲染，不是文本处理器
想保留 这类原始写法？得绕过解析阶段
DOMParser 的设计目标是构建 DOM 树，不是做字符串保真转换。一旦进入解析流程， 就注定变成 <code>。若你手头有一段含实体的 HTML 字符串（比如从 API 拿到的富文本），又想在前端展示其“源码形态”（即让用户看到 <code><div> 而不是 <code><div>），必须跳过解析环节：
<ul>
<li>直接用 <code>textContent 写入预格式化容器：preEl.textContent = rawHtmlStr —— 浏览器自动把所有 、<code>& 当纯文本显示
escapeHtml()（如把 → <code>），再塞进 <code>innerHTML；但注意顺序：必须先处理 &，否则 会被二次转成 <code><
<，前端拿到后解析一次得 ，再用 <code>textContent 显示才安全
innerHTML 和 textContent 的行为差异直接影响特殊符号呈现
这是最容易混淆的点：两者根本不在同一抽象层。
-
innerHTML是“HTML 解析入口”：赋值后触发完整解析流程，所有实体解码、标签构建、脚本执行（除非 sandbox）一并发生 -
textContent是“纯文本出口”：读取时返回去标签、去实体的结果；写入时把整个字符串当普通文本插入，和 <code>&不会被识别为语法符号 - 错误用法示例：
el.innerHTML = '<script>alert(1)</script>'→ 页面弹窗；而el.textContent = '<script>alert(1)</script>'→ 屏幕上原样显示那串字符
解析引擎选型要看输出目标：DOM 操作 or 字符串处理
如果你最终要操作节点（比如删掉所有 script 标签、提取链接、修改 class），DOMParser 是唯一合理选择；但如果你只是想“显示一段带 & 的字符串”，它反而制造麻烦。
- 需要 DOM 操作 → 用
DOMParser，接受它自动解码的特性，后续用textContent提取纯文本 - 只需字符串保真 → 别碰解析器，用
textContent直接写入，或用正则 + 映射表做可控替换（escapeHtml()函数） - 混合场景（如渲染用户提交的 HTML，但禁止执行脚本）→ 用
DOMPurify.sanitize()，它基于 DOMParser 构建，但提供白名单过滤，比手动解析更可靠
真正难的不是“怎么解析”，而是明确你要的是解析后的语义结构，还是原始字符串的视觉保真——这两个目标天然冲突，没有银弹函数能同时满足。
