SymfonyHtmlSanitizer 不直接过滤 XSS，而是通过解析、丢弃非法标签/属性、重建合法 HTML 来实现安全；其安全性完全取决于显式配置的白名单，且仅保障 HTML 上下文安全。
为什么 SymfonyHtmlSanitizer 不能直接过滤 XSS？
它本身不“过滤”，而是「重建」HTML：解析输入，丢弃非法标签/属性，再序列化合法结构。所以你传入 <script>alert(1)</script>，它不会留着标签再删内容，而是压根不进 AST——根本没机会执行脚本。
常见错误是以为它像正则替换一样“删掉 script 标签”，结果发现 <img src=x onerror=alert(1)> 还在，其实是因为默认配置没禁用 onerror 这类事件属性。
- 默认只允许基础标签（
p,strong,a等）和安全属性（href,class），所有事件处理器、style、data-属性全被清除 - 若需保留链接，必须显式允许
a[href]；若要支持图片，得加img[src]并限制协议（如只允https:） - 不处理 CSS 内联样式或 JS 字符串里的 HTML —— 它只管顶层 HTML 字符串解析
怎么配出真正安全的白名单？
别用默认配置。SymfonyHtmlSanitizer 的安全性完全取决于你写的 HtmlSanitizerConfig。放行一个危险属性（比如 iframe[srcdoc] 或 svg/onload），就等于开门。
典型场景：富文本编辑器输出要渲染，但用户不能执行 JS、不能加载外部资源、不能改样式。
立即学习“前端免费学习笔记（深入）”；
- 用
allowElements()显式列出所有可用标签，例如['p', 'br', 'strong', 'em', 'a', 'ul', 'ol', 'li']</li> <li>用 <code>allowAttributes()->onElements()
控制属性，比如allowAttributes(['href'])->onElements(['a'])，且对href加协议限制：withAllowedProtocols(['https', 'http']) - 禁止所有事件属性：不调用
allowAttributes()就默认全禁；显式写denyAttributes(['on.*'])更保险（正则匹配） - 禁用
style属性：别加style到允许列表，它默认不在白名单里，但有人会误加
SymfonyHtmlSanitizer 和 HtmlPurifier 性能差多少？
快很多。它基于 Symfony 自研的轻量 HTML 解析器，无外部依赖，不做 DTD 验证，也不处理废弃标签逻辑。实测千字 HTML 处理耗时通常在 0.5–2ms（PHP 8.2，本地环境），而 HtmlPurifier 常超 10ms。
但代价是：不兼容古董 HTML（如自闭合 <br> 不写斜杠会被当成开始标签），也不修复嵌套错误（<p><div>xxx</p></div> 可能被截断）。
- 适合现代服务端渲染场景，输入基本合规（如来自 TinyMCE、CKEditor 的输出）
- 不适合清洗爬虫抓取的野鸡网页源码——那种场景还是上
HtmlPurifier或DOMDocument+ 手动清理 - 注意内存：它会把整个 HTML 构建成 DOM 树，超大文本（>1MB）可能触发内存限制，建议前端先截断
为什么用了 SymfonyHtmlSanitizer 还有 XSS？
大概率是漏了上下文。它只保 HTML 结构安全，不负责后续使用方式。比如你把净化后的内容拼进 innerHTML 是安全的，但若塞进 eval()、setTimeout() 或作为 JS 字符串模板，就又危险了。
另一个高频坑：用 htmlspecialchars() 二次转义净化后的 HTML —— 这会让 <p> 变成 <p></p>，页面直接显示源码。
- 净化后的内容只能用于 HTML 上下文（如 Twig 的
{{ html|raw }}），不能用于 JS 字符串、URL 参数、CSS 值 - 如果要插进 JS，得用 JSON 编码：
JSON.stringify(sanitizedHtml)，而不是直接拼接 - 别在净化前做任何 HTML 实体解码（如
html_entity_decode()），否则<script></script>会变回<script>，绕过解析
最麻烦的点其实是信任链断裂：前端传来的数据，后端净化后存库，前端再取出来渲染——只要中间任意一环绕过净化（比如 API 直接返回原始字段），整条链就失效了。这事没法靠单个组件兜底。
