我蹲在一个安全研究群里看别人撕逼，只用有人丢了个链接，户输说某个知名论坛的地方都存洞私信功能能打XSS。底下立刻有人回：“私信？只用那玩意早该修了。”结果发链接的户输人贴了张图，payload是地方都存洞``，居然在最新版Chrome里弹了窗。只用评论区瞬间安静了两秒，户输然后炸锅。地方都存洞

这种戏码我见得太多了。只用不是户输修不修的问题，是地方都存洞压根没人把“用户输入”当回事。你去看那些后台管理系统，只用搜索框、户输日期选择器、地方都存洞甚至导出文件的文件名参数，全是从URL直接拼出来的。开发的时候图省事，`$_GET['keyword']`往SQL里一塞，顺手echo到页面上，完事。等哪天有人往keyword里塞个`.png`，前端把文件名直接插进img标签的alt属性里，引号一闭合，脚本就跑起来了。

更操蛋的是，很多开发用框架，以为框架自带防护就万事大吉。Vue、React默认转义没错，但架不住有人用`v-html`、`dangerouslySetInnerHTML`。我见过一个前端，为了渲染富文本编辑器内容，直接`v-html`后端返回的字符串，理由是“后端已经过滤过了”。可后端的过滤是黑名单，黑名单总有绕过姿势，什么大小写混写、编码嵌套、事件属性里塞空格换行，分分钟把filter打成筛子。

说句难听的，XSS漏洞根本杀不完。因为它的根子不在某段代码，而在人的惰性。只要有人觉得“这个输入只有我自己能填”，或者“攻击者怎么会想到这种地方”，漏洞就永远在。我甚至见过一个内部工具，把用户输入的Markdown直接转HTML，连白名单都没做。问就是“内网怕什么”，结果内网一台机器被钓鱼，横向移动就靠这个工具里的XSS拿到了域管权限。

所以别指望一劳永逸的修复方案。该做的就三件事：所有输出按上下文编码，输入校验只做白名单，关键操作上CSRF token。但更重要的，是每次写代码时都问一句——如果这里被塞了段脚本，会发生什么？想清楚再提交，比啥都强。