直接用 innerHTML 插入用户输入会引发 XSS 和 DOM 错乱，因浏览器将 <script> 等字符解析为 HTML；关键在于按上下文（文本节点、属性值、JS 字符串等）精准转义或使用 textContent/DOMPurify。
为什么直接用 innerHTML 插入用户输入会出问题
因为浏览器会把字符串里的 <script>、"、& 这类字符当作 HTML 语法解析，导致 XSS 或 DOM 结构错乱。比如用户输入 <img src=x onerror=alert(1)>，直接赋给 innerHTML 就执行了脚本。
核心不是“要不要转义”，而是“在哪一环做、用什么方式做”。服务端转义漏掉字段、客户端重复转义、富文本场景硬套转义——都会翻车。
- 纯文本展示（如评论内容）：必须转义
<、>、"、'、& - 属性值内插（如
title="${userInput}"）：额外注意"和'，否则提前闭合引号 - JSON 输出到 inline script 中：得用
JSON.stringify()，不是简单替换<，否则引号和反斜杠会破坏 JS 语法
DOMPurify 能不能代替手动转义
能，但要看场景。它不是“转义函数”，而是 HTML 清洗器：接收一段 HTML 字符串，删掉危险标签/属性，保留白名单内的结构。适合富文本编辑器输出渲染，不适合纯文本字段。
常见误用：DOMPurify.sanitize('<div>hello</div>') 看似安全，但如果原始数据是纯文本（比如用户名），其实该用 textContent —— 更快、零风险、不引入额外依赖。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 用
DOMPurify前先确认：这段内容是不是真的含 HTML？还是只是用户随便打了几个<符号？ - 配置不当会导致绕过：默认不开启
SAFE_FOR_TEMPLATES，data-*属性可能被保留，而某些前端框架会监听这些属性触发执行 - 体积不小（约 30KB min+gzip），简单页面没必要为防 XSS 引入整个库
服务端转义后前端再用 textContent 是不是多余
不多余，而且推荐。服务端转义解决的是传输过程中的注入风险（比如模板引擎拼接），但前端拿到的数据如果被二次拼接到 HTML 字符串里，依然可能出问题。
例如后端返回 JSON：{"name": "<script>..."}，前端写成 el.innerHTML = '<span>' + data.name + '</span>'，服务端那层转义就白做了。
- 最稳做法：服务端只做最小必要转义（如模板中变量插值），前端一律用
textContent或setAttribute()写入动态内容 - React/Vue 等框架默认做了转义，但仅限于 JSX/模板表达式；一旦用
dangerouslySetInnerHTML或v-html，就得自己确保输入已清洗 - API 返回的字段用途要明确标注：是 raw text？HTML fragment？还是可执行脚本？不同用途对应不同处理链路
哪些字符必须转义、哪些可以不管
基础五字符是底线：&、<、>、"、'。其它如 、© 属于语义字符，不转义不影响安全，只影响显示。
容易忽略的点：URL 参数里的特殊字符（如 ?、=、&）不属于 HTML 转义范畴，得用 encodeURIComponent() 编码；而 CSS 里的 url() 函数内也要单独处理，不能混用 HTML 转义逻辑。
-
&必须最先转义，否则后续转义结果里出现会被浏览器再次解析成 <code>< -
/（即/的 Unicode 实体）在某些旧版 IE 中可绕过过滤，但现代场景基本不用管 - 中文、emoji、全角符号本身无需转义，它们不是 HTML 元字符，直接放
textContent安全
escapeHtml()”当成银弹。真正关键的是分清上下文：是在 HTML 文本节点？属性值？JS 字符串？URL？每个位置的安全边界和编码规则都不一样。 
