dangerouslySetInnerHTML 会绕过 React 的 HTML 实体转义，直接执行恶意脚本；必须配合 DOMPurify 等净化工具使用，且 html-react-parser 和 react-markdown 也需正确配置才能防御 XSS。
dangerouslySetInnerHTML 为什么不能直接用
React 默认对 {userInput} 做 HTML 实体转义，所以 <script>alert(1)</script> 会原样显示为文本。但一旦你写 dangerouslySetInnerHTML={{__html: userInput}}，这套防护就完全失效——浏览器会真实解析并执行其中的 <script>、<img onerror="...">、<svg onload="...">。
常见错误现象包括：评论区点击图片弹出 cookie、富文本编辑器保存后页面白屏、后台返回的 HTML 片段触发无限重定向。
- 永远不把未过滤的用户输入、表单值、URL 参数直接塞进
__html - 即使内容来自“可信后端”，也要确认它没经过中间代理篡改或缓存污染
- 注意 SSR 场景：服务端渲染时若用
dangerouslySetInnerHTML渲染未净化内容，首屏就可能执行脚本
DOMPurify 是目前最稳妥的 HTML 净化方案
它不是简单删掉 <script> 标签，而是基于 HTML 规范重建 DOM 树，剔除所有危险节点、属性和协议（如 javascript:、data:text/html）。相比正则过滤，它能处理嵌套、注释绕过、大小写混淆等边缘 case。
安装和基础用法很简单：
立即学习“前端免费学习笔记（深入）”；
npm install dompurify
使用时注意两点：
-
DOMPurify.sanitize()返回的是字符串，不是 React 元素，必须配合dangerouslySetInnerHTML或第三方解析器使用 - 默认配置已禁用 script、object、embed 等高危标签，但若需保留
<style>或内联onxxx事件，必须显式配置白名单，不建议这么做 - 在 Web Worker 中调用可避免主线程阻塞，尤其适合长文本批量净化
html-react-parser 比 dangerouslySetInnerHTML 更安全，但仍有陷阱
它把 HTML 字符串解析成 React 元素树，天然避开 innerHTML 的执行链路，且支持自定义 tag 映射（比如把 <code> 替换为 SyntaxHighlighter 组件）。但它本身不做内容净化——如果传入的 HTML 已含恶意代码，它照样解析并挂载。
正确用法是组合使用：
import parse from 'html-react-parser';
import DOMPurify from 'dompurify';
const cleanHtml = DOMPurify.sanitize(dirtyHtml);
const reactNode = parse(cleanHtml, {
// 只允许 class、src、alt 等安全属性
attributes: { allowList: ['class', 'src', 'alt', 'href'] },
// 自定义处理 code 标签
replace: (domNode) => {
if (domNode.name === 'code' && domNode.children?.[0]?.type === 'text') {
return <code>{domNode.children[0].data}</code>;
}
}
});
容易踩的坑：
- 误以为
parse()自带 XSS 防护，跳过DOMPurify.sanitize() - 在
replace回调里拼接用户输入生成新属性（如style={{ backgroundImage: `url(${domNode.attribs.src})` }}），仍可能触发 CSS 注入 - 忽略 SVG 内联脚本：DOMPurify 默认清理 SVG 脚本，但若配置了宽松的
ADD_TAGS，需额外检查onload、onerror属性
react-markdown 是 Markdown 渲染的首选，不是 HTML 解析器
如果你实际要渲染的是 Markdown（比如博客正文、文档页面），别用 dangerouslySetInnerHTML + marked，直接上 react-markdown。它基于 remark 构建 AST，所有输出都走 React.createElement 流程，天然免疫 XSS。
关键点：
- 它不接受原始 HTML 字符串作为输入；若传入含 HTML 的字符串，需启用
skipHtml: false并搭配remarkPlugins: [remarkGfm]，此时内部仍会调用 DOMPurify - 自定义组件映射（如把
<h2>换成Heading）不会破坏安全性，因为映射发生在 AST 渲染阶段，而非字符串拼接 - 数学公式、表格、任务列表等功能靠插件扩展，不用自己写正则或 DOM 操作，代码质量更可控
真正难处理的从来不是语法解析，而是混合场景：比如 Markdown 正文中嵌入一段由富文本编辑器生成的 HTML 片段。这时候必须拆解——先用 DOMPurify 净化 HTML 片段，再通过 react-markdown 的 components prop 插入，而不是试图让一个工具包揽全部。
