响应拦截器不适合直接过滤富文本xss，因其无法预知富文本字段名、易误伤正常字段且缺乏渲染上下文；应改在组件内、组合式函数或编辑器输入阶段按需净化，并始终配合后端校验。
响应拦截器本身不适合直接对富文本内容做 XSS 过滤。
为什么不能在响应拦截器里过滤
响应拦截器（如 Axios 的 response interceptor）运行在请求完成、数据刚返回但尚未进入业务逻辑的阶段。此时你拿到的是原始响应体（可能是 JSON 对象），但富文本字段通常只是其中某个字符串字段（比如 data.content），而：
- 你无法预知哪个字段是富文本——不同接口字段名不统一（
desc、body、htmlContent都可能出现）； - 统一清洗所有字符串字段会误伤正常业务字段（如用户名含单引号、地址含尖括号）；
- 过滤必须结合上下文：是用于
v-html？还是纯文本展示？是否允许图片或链接？白名单需按场景配置，拦截器做不到灵活适配。
正确的过滤时机和位置
XSS 过滤应当发生在**使用前**，而非“返回时”。推荐在三个明确位置处理：
-
组件内按需调用：在需要渲染富文本的组件中，对具体字段显式净化。例如：
const safeHtml = DOMPurify.sanitize(apiResponse.data.content)，再传给v-html； -
封装可复用的组合式函数：新建
useSanitizedHtml.ts，接收原始 HTML 和可选配置，返回响应式净化结果； -
富文本编辑器输入阶段拦截：如使用 Quill 或 wangeditor，在
text-change或onBlur时就调用DOMPurify.sanitize()处理用户输入，从源头控制。
如果坚持要在请求层介入，可行的折中方案
仅适用于内部系统、字段命名高度规范的场景：
- 约定所有富文本字段统一用
html_前缀（如html_description、html_content）； - 在响应拦截器中递归遍历响应数据，对匹配字段名的字符串值执行
DOMPurify.sanitize()； - 必须配合严格白名单配置（禁用
script、iframe、事件属性等），且仅启用SANITIZE_DOM: false（避免 DOM 操作引发副作用）； - 该方式仍需在组件中二次确认——拦截器只做初步清洗，最终渲染前仍建议再调用一次
sanitize()并传入当前组件所需的最小白名单。
关键提醒
无论在哪一层过滤，都必须：
- 始终使用
DOMPurify.sanitize(html, config)显式传入配置对象，不要依赖默认行为； - 后端必须同步做服务端净化，前端过滤仅为体验优化，不可替代后端校验；
- 禁止在拦截器里修改原始响应对象的引用（如直接赋值
res.data.xxx = ...），应返回新对象避免污染其他业务逻辑。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
