HTML转义本质是防止浏览器误解析为标记，仅需转义<、>、&、"、'五类元字符；中文引号、©等Unicode字符在UTF-8中可直接使用；textContent安全，innerHTML可能触发二次解析漏洞。
HTML转义不是用来“适配”特殊字符的
HTML转义的本质是防止字符被浏览器误解析为标记，而不是为了让特殊字符“正常显示”。比如 < 转义后变成 ，浏览器才不会把它当开始标签；但如果你本来就想显示一个数学小于号，那这个转义就是必须的——不是为了“适配”，而是为了“不破坏解析”。常见错误是把用户输入的中文引号、破折号、版权符（<code>©）也一股脑转义成 © 或 ©，结果页面反而出现字面的 © 文本，因为这些字符本身完全合法，不需要转义。
- 只需对 HTML 元字符做转义：
<、>、&、"、' -
©、®、—、“等 Unicode 字符，在 UTF-8 页面中可直接写入，无需实体替换 - 若后端返回的是已转义字符串（如
<script></script>），前端再调用textContent渲染就安全；但若用innerHTML直接插入，且字符串里混有未转义的&，可能触发二次解析漏洞
JavaScript 中 textContent 和 innerHTML 的行为差异
这是最容易踩坑的地方：你以为做了转义，但渲染方式让转义失效。比如后端返回 <img src="x" onerror="alert(1)" alt="HTML转义和特殊字符有区别吗_HTML转义适配特殊字符策略【指南】" >，你用 element.innerHTML = str 插入，浏览器会先解码 成 <code>，再执行标签解析——XSS 就这么来了。而 <code>element.textContent = str 会原样输出所有内容，连 都当纯文本。
- 显示用户可控内容时，优先用
textContent（或innerText），它自动规避所有解析风险 - 必须用
innerHTML时，确保输入已通过可信库（如 DOMPurify）过滤，而非仅靠简单字符串替换 - 不要自己写正则去“反转义”再“重转义”，
DOMParser解析 +textContent提取是更可靠的清洗路径
服务端转义函数要不要保留 htmlspecialchars(..., ENT_QUOTES) 的 ENT_SUBSTITUTE 标志
PHP 的 htmlspecialchars 默认遇到非法 UTF-8 字节序列会返回空字符串，这会导致页面内容莫名消失。加 ENT_SUBSTITUTE 可让其用 替换坏字节，至少保全文本可见性。但注意：这个标志不影响标准转义逻辑，只处理编码异常。
- Web 页面声明了
UTF-8，就应确保所有输入也是合法 UTF-8；ENT_SUBSTITUTE是兜底，不是替代编码校验 - Node.js 中
he.escape()默认已处理无效码点，无需额外配置；但若用原生String.prototype.replace()手动实现，必须先Buffer.from(str, 'utf8').toString()校验 - 数据库字段编码（如 MySQL 的
utf8mb4）和连接层编码（SET NAMES utf8mb4）没对齐，会导致存进去就是乱码，转义再全也没用
JSON 传输中的双转义陷阱
前后端用 JSON 交互时，常有人在服务端对字段值先 HTML 转义，再塞进 JSON；前端 JSON.parse() 后直接 innerHTML = data.content。问题在于：JSON 字符串里的 是普通字符，<code>JSON.parse() 不会自动解码 HTML 实体——所以你看到的就是字面的 四个字符。
立即学习“前端免费学习笔记（深入）”；
- 正确做法：服务端不 HTML 转义，只保证 JSON 输出合法（如引号、反斜杠转义）；前端收到后，按需用
textContent或经净化后再innerHTML - 如果必须传已转义内容（如 CMS 富文本字段），前端要用
he.unescape()或DOMParser显式解码，不能依赖任何自动行为 - Vue/React 模板中插值（
{{ content }}或{content}）默认是 textContent 级别，不触发 HTML 解析，所以服务端转义反而多余
最常被忽略的一点：转义不是目的，控制渲染上下文才是。同一个字符串，在 textarea.value、title 属性、data-* 属性、CSS content 伪元素里，需要的转义规则完全不同——没有银弹策略，只有按场景选方法。
