必须在服务端用dom解析器做白名单净化，且入库前和渲染前各执行一次；htmlspecialchars()仅适用于纯文本字段，处理富文本会降级为纯文本并忽略属性危险内容。
服务端渲染 HTML 时，仅靠前端过滤或简单转义无法防住 XSS —— strip_tags() 留下危险属性，htmlspecialchars() 把富文本变成纯文本，而正则替换根本拦不住变体攻击（比如 <script></script> 或换行绕过）。真正能落地的安全加固，必须在服务端用 DOM 解析器做白名单净化，且必须在入库前和渲染前各执行一次。
为什么不能只用 htmlspecialchars() 处理富文本
它把所有 、<code>>、& 全部转义，用户发的 <strong>加粗</strong> 会原样显示为“加粗”，不是渲染成加粗文字。这不是过滤，是降级为纯文本展示 —— 富文本字段就废了。
更关键的是：它不处理属性里的危险内容。比如用户提交：@#@#@#@#@#@#@#@#@#@0，htmlspecialchars() 只转义标签符号，href 值照进数据库，后端一拼进模板就触发执行。
- 适用场景：仅用于纯文本字段（如用户名、评论摘要）的输出转义
- 不适用场景：富文本编辑器（TinyMCE、Quill）提交的内容、后台 CMS 的正文字段
- 替代方案：必须用 HTML 解析器重建 DOM，而非字符串替换
PHP 服务端该用 HTMLPurifier 还是 XssHtml
优先选 HTMLPurifier：它基于真实 HTML 解析，支持完整白名单配置、CSS 属性控制、URI 协议校验，还能修复畸形 HTML（比如未闭合的 <p></p>），长期维护活跃，文档清晰。
XssHtml 依赖 DOMDocument，对 malformed HTML 容错强，但默认不校验 style 中的 background-image: url(javascript:...)，需手动开 CSS.AllowTricky 并显式放行允许的 CSS 属性，配置稍重。
- 必须配置
'URI.AllowedSchemes' => ['http', 'https', 'mailto']，否则data:、javascript:会漏掉 - 图片
style被清空？不是 bug，是默认策略 —— 要保留background-size得加进CSS.AllowedProperties - 禁用
script、iframe、object、embed标签，不能只写ALLOWED_TAGS，还得配FORBID_TAGS双重保险
过滤必须在入库前 + 渲染前各做一次
很多人只在渲染时净化，这是错的。恶意 HTML 进了数据库，后续导出、API 输出、邮件模板、管理后台预览都可能中招 —— 一次入库，处处风险。
正确流程：接收到 POST 数据 → 立即用 HTMLPurifier::clean() 净化 → 存入数据库 → 渲染前再次调用（哪怕数据来自自己库）→ 拼进模板。
- 入库前净化：防止脏数据污染存储，避免后续所有消费方踩坑
- 渲染前再净化：防御数据库被拖库后原始数据被直接读取、或缓存污染导致绕过
- 别省这一步 —— 即使你确定数据“干净”，也要走一遍，因为信任链可能断裂（比如定时任务直读 DB 绕过业务层）
DOMPurify 在前端只是体验优化，不是安全防线
用户粘贴一段带 <img src="x" onerror="alert(1)"> 的 HTML，DOMPurify.sanitize() 确实能干掉。但攻击者不会走这一步：curl 直 POST、Postman 改请求、禁用 JS 后填表单 —— 所有前端过滤形同虚设。
Vue 里别用 v-html 绑定未净化内容，React 别碰 dangerouslySetInnerHTML —— 即使你刚调过 DOMPurify.sanitize()，也要确保变量来源是后端已净化过的字段，而不是原始 textarea.value。
- 表单
submit时可调一次轻量DOMPurify.sanitize()做预览，但原始值仍要发给后端 -
input事件实时清理非法字符？只能拦正常输入，拦不住粘贴、拖放、语音输入，和安全无关 - 真正可信的净化环节只有一个：服务端接收请求后的第一道处理
最常被忽略的一点：富文本字段的 href 和 src 必须单独校验协议，不能只靠标签白名单。比如 <a href="javascript:alert(1)"></a> 在白名单里，但协议非法 —— HTMLPurifier 默认会拦，但自定义过滤器若没配 URI.AllowedSchemes 就会漏。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
