HTML解析器遇&会启动实体识别状态机，从&开始扫描至分号；若无分号则延迟终止，导致额外字符遍历、哈希查表及可能的进制转换开销，高频出现时性能线性下降。
HTML解析器遇到&时会触发完整实体扫描
浏览器解析HTML文本时，只要看到&字符，就会启动一个“实体识别状态机”：从&开始，向后扫描直到遇到;，中间所有字符都会被当作潜在实体名或数字码点处理。哪怕后面只是&foo;这种不存在的实体，也得走完识别流程。
这意味着：&不是简单替换，而是强制进入一次子解析循环。在大量文本中高频出现&（比如日志、代码片段、数学公式），这个开销会线性增长。
- 每遇到一个
&，至少多做1次字符遍历 + 1次哈希查表（查命名实体） - 如果后面没跟
;（如<），解析器会等到标签结束或换行才放弃，更慢 -
...和...比<多一次进制转换计算
转义顺序错误会让&数量翻倍
常见错误写法：text.replace(/, '——先转<code>，再转<code>&，结果把原本的<变成，白增一个<code>&。
这不只是语义错误，更是性能陷阱：后续所有解析都得多扫一遍新增的&，尤其在富文本渲染或服务端模板批量处理时，可能让首屏解析延迟增加数毫秒。
立即学习“前端免费学习笔记（深入）”；
- 正确顺序永远是：
&→→ <code>>→"→' - 正则全局替换比逐字符遍历快，但必须保证单轮完成，不能链式调用
- Node.js里用
String.prototype.replaceAll()比.replace()更安全（避免遗漏）
textContent vs innerHTML 的底层差异
用textContent = str完全绕过HTML解析器；而innerHTML = str强制触发完整词法分析+语法树构建。前者是纯内存赋值，后者要走 tokenizer → parser → DOM builder 全流程。
即使str里全是普通文本，innerHTML也会为每个&启动实体识别——这是不可省略的合规检查，不是优化可跳过的步骤。
- 显示用户评论？优先
el.textContent，零解析开销 - 必须渲染富文本？用
DOMPurify.sanitize()代替手动转义，它复用浏览器原生解析器但只保留白名单节点，比纯字符串替换更稳且不重复解析 - 服务端预转义后的字符串，前端仍用
textContent——不是冗余，是堵住innerHTML拼接漏洞的最后一道闸
Unicode私有区字符和实体编码无关
像😀（?）这类emoji，浏览器直接按UTF-8解码显示，不经过实体解析流程。但如果你写成😐（十进制），就得走数字实体转换路径，多一次整数解析。
真正拖慢解析的，从来不是字符本身，而是&引发的状态切换。所以：能用UTF-8原文本就别用数字实体，除非目标环境明确不支持（如老旧邮件客户端）。
-
?（UTF-8）→ 直接字节流解码 -
😊→ 触发十六进制实体识别 -
😊→ 触发十进制实体识别 + 进制转换
&字符就像一个开关，一按下去，整个HTML解析器就进入另一个工作模式——这个切换成本，在高并发或低配设备上会立刻暴露。 
