本文介绍在 react 中正确渲染富文本 html 邮件内容的两种主流方案，重点分析 `dangerouslysetinnerhtml` 的局限性，并推荐更可靠、样式隔离性更强的 `
在 React 应用中渲染第三方 HTML 邮件内容（如营销邮件、通知模板）是一个常见但易被低估的挑战。许多开发者第一反应是使用 dangerouslySetInnerHTML：
该方式虽能解析 HTML 标签，但存在两大核心问题：
✅ 样式污染：邮件内联的 CSS（如
而
✅ 样式完全隔离：iframe 创建独立的 DOM 和 CSSOM 上下文，邮件内所有样式仅作用于其内部，彻底避免与主应用样式冲突；
✅ 安全边界明确：默认禁用脚本、表单提交、弹窗等高风险行为；通过 sandbox 属性可精细控制能力（如仅允许同源脚本）；
✅ 语义准确：HTML 邮件本质是独立文档，iframe 正是为嵌入外部文档而设计的标准语义化元素。
⚠️ 注意事项：
- 确保 emailHtml 是完整 HTML 文档结构（含 ），否则部分浏览器可能渲染异常；若仅有片段（如 ...），建议包裹为标准文档：
const wrappedHtml = `${emailHtml}`; - 在生产环境，务必对 emailHtml 进行服务端清洗（如使用 DOMPurify），即使使用 iframe，也应防范 javascript: 协议或 data: URI 攻击；
- 若需响应式适配，可在 srcdoc 内注入媒体查询或 viewport meta 标签；
- Safari 对 srcdoc 的 sandbox 支持较新（iOS 15.4+/macOS 12.3+），旧版需降级为 src="data:text/html,..." 或服务端代理。
综上，对于 HTML 邮件预览这类强样式依赖、来源不可控的场景，
