HTML转义是必须的，关键在于位置、方法和次数；仅需转义五个基础字符：&、、"、'，其中&最危险；命名实体用于ASCII符号，数字编码更通用；innerHTML插入前必须转义，textContent仅适用于纯文本场景。
直接说结论：HTML转义不是“要不要做”的问题，而是“在哪做、怎么做、做几遍”的问题。不加区分地全量转义或漏掉关键字符，都会导致显示异常或XSS漏洞。
哪些字符必须转义？
只有五个基础字符在绝大多数场景下必须转义，它们是：&、、>、"、'。原因很实在：浏览器解析HTML时，遇到&会尝试匹配实体（如），遇到或>可能误启标签解析，而引号在属性值中若未转义会导致属性截断。
-
&是最危险的——所有实体都以它开头，未转义的&可能让 和>在纯文本内容中不一定出错，但一旦混入用户输入（如评论、搜索关键词），就极易被构造为<script></script>或-
"和'主要在属性值内生效，比如title="用户输入了"——如果用户输的是">，就会提前闭合属性，插入恶意代码
什么时候该用数字编码（…;）而不是命名实体（
命名实体（如）可读性好，但支持有限；数字编码（如或）覆盖全部Unicode字符，且更稳定。实际选型看场景：
- 日常开发优先用
、>、&等命名实体——语义清晰，编辑器友好 - 处理非ASCII字符（如中文、emoji、数学符号）时，用
XXXX;更可靠，例如→（→）、😊（?） - 模板引擎或服务端渲染（如Java的
StringEscapeUtils.escapeHtml4()）默认输出数字编码，避免依赖命名实体表 - 注意：
是空字符，某些老版本IE会崩溃，绝对禁用
前端JS里用innerHTML插入内容前必须转义吗？
必须。因为innerHTML会触发HTML解析，等于把字符串交由浏览器二次编译。哪怕只是显示一段用户昵称，只要没转义，就可能执行脚本。
- 别信
textContent能“代替”转义——它确实安全，但只适用于纯文本场景；一旦需要保留部分HTML（如富文本评论里的<br>
），就必须走严格转义+白名单过滤 - 简单方案：用
document.createElement('div').textContent = str再取.innerHTML，本质是借浏览器原生转义逻辑，但性能差、不支持批量 - 生产环境推荐轻量函数，例如：
function escapeHtml(str) {
if (typeof str !== 'string') return '';
return str
.replace(/&/g, '&')
.replace(/, '/g, '>')
.replace(/"/g, '"')
.replace(/'/g, ''');
}
注意：正则里/不能写成/\/g——斜杠不是特殊字符，不需要转义；但'在单引号字符串里必须写成\'或改用双引号包裹正则。
服务端转义和前端转义能互相替代吗？
不能。二者职责不同，漏掉任一环都可能被绕过。
- 服务端转义（如PHP的
htmlspecialchars($str, ENT_QUOTES)）是第一道防线，防止存储型XSS——恶意内容写入数据库前就被拦住 - 前端转义是最后一道防线，防反射型XSS和DOM型XSS——比如URL参数
?q=<script>alert(1)</script>直接拼进页面 - 常见坑：后端转义了，前端又用
v-html（Vue）或dangerouslySetInnerHTML（React）原样插入，等于白转；或者前端转义了，后端却把已转义的内容再次转义，结果页面显示 - 关键原则：数据在哪一端被解释为HTML，就在哪一端做转义。永远假设“上游传来的字符串是不可信的”
最容易被忽略的点：JSON接口返回的字符串，如果前端用innerHTML直接插入，那JSON本身不转义也没用——转义动作必须落在插入前那一行代码上，而不是API响应头里。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
