vue中{{ }}插值默认转义足够防xss，它是第一道防线；vue会对变量中的、&等字符自动转义为html实体，使恶意脚本如alert(1)仅显示为纯文本而不会执行。
Vue中{{ }}插值默认转义是否足够防XSS
不够，但它是第一道防线。Vue在{{ }}中对变量内容做HTML实体转义（比如把），所以直接写{{ userInput }}不会执行脚本。但这个机制只作用于纯文本上下文，一旦你用v-html、innerHTML、document.write或模板字符串拼接，转义就失效了。
常见错误现象包括：console.log(`Hello ${userInput}`)后又把它塞进innerHTML；或者误以为{{ }}能“兜底”所有场景，结果在:class或:style绑定里传入未过滤的用户字符串，触发CSS表达式或JavaScript URL协议注入。
- 仅靠
{{ }}无法防御DOM型XSS，比如从location.hash或localStorage读取后直接赋值给innerHTML -
{{ }}不处理属性绑定中的特殊字符，:href="userInput"若含javascript:alert(1)仍会触发 - 服务端返回的富文本若未经净化就交给
{{ }}，虽然标签被显示为文字，但可能藏有编码绕过（如<script></script>）
什么时候必须用DOMPurify.sanitize()而不是{{ }}
当你明确需要渲染用户提交的富文本（比如评论、文章正文、后台编辑器输出）时，{{ }}就该让位给DOMPurify.sanitize()。它不是简单转义，而是解析HTML、按白名单策略重建DOM树，移除<script></script>、危险属性（onerror、href="javascript:"）、data: URI等。
使用场景很具体：CMS后台富文本编辑器保存的内容、用户发帖带格式的正文、第三方API返回的HTML片段。
- 别在每次渲染前都调用
DOMPurify.sanitize()——性能开销大，建议存入数据库前就净化一次 - 不要用
v-html绑定原始userInput，必须先过DOMPurify.sanitize()再绑定 - 注意
DOMPurify默认不放行<svg></svg>和<math></math>，如有需求需显式配置ADD_TAGS和ADD_ATTR
v-html绑定前漏掉净化的典型后果
后果不是“可能出问题”，而是“必然可被利用”。攻击者只要提交一段形如<img src="x" onerror="alert(1)">或@#@#@#@#@#@#@#@#@#@0的内容，页面一渲染就会触发脚本执行。
更隐蔽的是基于CSS的XSS：比如<div style="background:url('javascript:alert(1)')">，在旧版Chrome或Safari中仍可执行；或利用<code>expression()（IE）或url('data:text/html;base64,...')绕过基础过滤。
- 即使你用了CSP，
unsafe-inline或unsafe-eval策略会让v-html里的内联事件直接生效 - 服务端若只做长度/格式校验，没做HTML结构解析，就等于把过滤责任全推给前端
- Vue 3的
defineModel或组合式API里，如果用unref()解包后直接塞进v-html，同样跳过所有转义逻辑
TypeScript类型系统如何辅助插值安全
TypeScript本身不防XSS，但它能帮你把“哪些数据是可信的、哪些必须净化”显式建模出来。比如定义type SanitizedHTML = string & { __brand: 'sanitized' }，再写一个sanitize(): SanitizedHTML函数，就能阻止开发者把原始string误传给v-html。
实际效果是编译时报错，而不是运行时被黑。比如const raw = getFromAPI(); vHtmlValue = raw;会报类型不匹配；只有vHtmlValue = sanitize(raw);才过。
- 避免用
as any或@ts-ignore绕过类型检查，这等于主动拆掉护栏 - 对来自
localStorage、URLSearchParams、postMessage的数据，默认视为string而非SanitizedHTML - 团队协作时，类型定义比注释更可靠——没人会认真读“此处需净化”的TODO，但TS报错躲不掉
DOMPurify流程，而不是靠经验判断。
