html解析器遇到&时立即进入实体识别状态，严格按标准向后扫描至分号;或非法字符终止，合法则解码，非法则原样保留。
HTML解析器遇到 & 时怎么判断是实体还是普通文本
解析器不是靠“猜”，而是严格按 HTML 标准的 & 消费规则来推进。一旦读到 &，它就进入“可能的实体识别状态”，接着向后扫描，直到遇到第一个非字母数字字符（比如 ;、空格、、<code>& 等）为止。
关键判断点有三个：
- 如果后续字符构成合法命名实体（如
、<code>©），且以;结尾 → 解析为实体，替换为对应 Unicode 字符 - 如果是
开头，后面跟十进制或十六进制数字（如、<code>），且以 <code>;结尾 → 同样解析为实体 - 否则（比如
&xyz、<、{、GZ;）→ 视为“无效实体”，&本身保留为文本，后续字符也原样保留（即不消费、不跳过）
注意：; 不可省略。没有分号的 < 不会被识别为 ，而会被当作普通文本中的 <code>& 加字母 lt —— 这正是很多“转义没生效”的根源。
为什么 在属性值里有时失效
因为 HTML 解析分“标签上下文”和“属性值上下文”，而属性值的引号类型会影响解析边界。例如：
<div title="He said " hi></div>
这里 " 出现在双引号包裹的属性值中，解析器会正确识别；但若写成：
<div title='He said "Hi"'></div>
单引号内用 " 是安全的；反过来，若在单引号属性里写 '，老版 IE 可能不认（HTML4 不支持 '），导致 & 被孤立，后续 apos; 变成明文。
更隐蔽的问题：属性值未加引号时，空格或 = 会提前截断实体识别。比如：
<input value="<script">alert(1)>
这个 根本不会被当实体处理——因为解析器在遇到空格前就已结束该属性值，<code> 被当作标签外的裸文本，甚至可能触发 XSS。
DOM API 返回的文本为什么“看不见”实体
因为实体解析发生在 HTML 解析阶段，不是 DOM 运行时行为。一旦元素被插入文档， 已变成真正的 U+003C 字符，<code>textContent 或 innerText 读出来的就是 ，不是原始字符串 <code>。
想拿到原始实体写法？基本做不到。只有以下路径保留源码痕迹：
-
innerHTML：返回已解析后的 HTML 字符串，但实体已被转换（→ <code>） -
outerHTML：同上，且包含标签结构 - 原始 HTML 字符串（如通过
fetch读取的响应体）：这才是唯一能看到的地方
所以，服务端渲染或模板引擎必须在生成 HTML 前完成转义；前端 JS 动态插入内容时，绝不能拼接原始用户输入到 innerHTML，否则实体不会被“二次解析”，反而直接执行。
常见误判场景：哪些字符根本不会触发实体识别
解析器只对 & 开头的序列启动实体识别流程。这意味着：
和 <code>>单独出现，永远只是标签符号或文本 —— 它们本身不是实体，也不会激活实体逻辑-
"、'、空格、换行等，只要不在&后面，就完全不参与实体机制 -
&出现在注释<!-- ... -->或<script></script>内部时，实体识别被暂停（脚本/样式内容按纯文本处理） -
&是唯一能安全出现在其他实体中间的实体 —— 因为<会被解析为，而不是报错
最易忽略的一点：URL 中的 &（如 ?a=1&b=2）本质是查询参数分隔符，不是 HTML 实体起始符。它是否需要双重转义（&），取决于它所处的上下文 —— 是写在属性值里？还是动态注入到 href 字符串中？混淆这两层，就会产出既不能点击又无法解析的链接。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
