React SharePoint WebPart中html-react-parser与dompurify渲染HTML的区别

两种富文本渲染方案的核心区别 #

1. 功能定位与安全性差异 #

• dompurify + eslint-plugin-risxss 组合
  这是专门针对XSS安全风险设计的双重防护方案：
  • dompurify的核心作用是HTML内容净化，会自动移除所有恶意脚本、on*事件属性、风险标签（如<iframe>、<script>）等攻击载体，只保留安全的富文本结构，是OWASP官方推荐的HTML安全处理工具，支持自定义过滤规则，可灵活控制允许的标签、属性范围。
  • eslint-plugin-risxss是开发阶段的静态检查工具，会自动扫描代码中未做净化就直接使用dangerouslySetInnerHTML的风险写法，从开发流程层面避免人为疏漏。
• html-react-parser 方案
  它的本质是HTML字符串转React元素的解析工具，默认不带任何XSS防护能力：如果直接传入包含恶意代码的HTML内容，它依然会解析并执行风险逻辑。如果要安全使用，你需要额外手动编写过滤规则（比如通过replace回调移除风险标签），或者还是要先通过dompurify净化内容后再传入解析，本身不能独立解决安全问题。

2. 渲染效果与扩展性差异 #

• dompurify方案直接通过dangerouslySetInnerHTML渲染净化后的原始HTML，对用户输入的HTML结构、自定义样式的还原度更高，完全匹配浏览器原生HTML渲染行为，适合你当前允许用户自由输入HTML的场景。
• html-react-parser会将HTML转换为React虚拟DOM元素，优势是可以对解析后的元素做React层面的细粒度控制（比如统一给所有<a>标签加target="_blank"、给图片加懒加载属性等），但复杂HTML结构的渲染效果可能和原始写法有细微差异，额外的转换逻辑也会增加开发成本。

3. 性能差异 #

• dompurify仅做字符串层面的净化处理，之后直接交给浏览器渲染HTML，性能开销更低，尤其是富文本内容较长的场景下优势更明显。
• html-react-parser需要先将HTML解析为AST语法树，再转换为React元素，多了两层转换开销，内容量大时性能弱于dompurify方案。

针对你的SharePoint WebPart场景的建议 #

你当前使用的dompurify + eslint-plugin-risxss方案已经完全满足需求，是更稳妥的选择：本身专门针对用户输入HTML的安全渲染场景设计，成熟度高，无需额外开发就能实现可靠的XSS防护。如果你没有对HTML元素做React层面自定义改造的需求，完全不需要切换到html-react-parser方案。

内容的提问来源于stack exchange，提问作者John John