凌晨三点，修复系统手机弹出一条推送：某开源库爆出远程代码执行漏洞，漏洞评分9.8。修复系统我盯着屏幕愣了几秒，漏洞那个库我上周刚集成进一个内部工具。修复系统爬起来开电脑，漏洞第一件事不是修复系统改代码，而是漏洞先确认版本号——果然，中招了。修复系统

修复漏洞这件事，漏洞最怕的修复系统不是漏洞本身，而是漏洞你不知道它到底影响多大。官方公告只说了“建议升级到最新版”，修复系统可最新版又引入了两个不兼容的漏洞API变更。你升还是修复系统不升？升了，现有功能可能崩；不升，攻击者可能从某个你没注意到的入口打进来。这种两难，每个运维和开发都遇到过。

我见过最离谱的一次，是一个电商后台的SQL注入。漏洞报告写得含糊，只说“搜索参数未过滤”。开发团队扫了一眼代码，觉得用了ORM框架，不可能有注入。结果呢？他们在一个导出报表的接口里，图省事直接拼接了字符串。那个接口半年没人用过，连测试用例都没覆盖。攻击者怎么找到的？没人知道。修复只花了十分钟，加个参数化查询就完事。但定位问题花了整整两天。

所以修复漏洞的第一步，从来不是写补丁，而是搞清楚“谁在什么条件下能触发它”。很多团队一看到漏洞就慌，恨不得立刻重启服务、回滚版本。回滚确实能暂时止血，但如果你连漏洞的触发路径都没弄明白，回滚之后照样可能被另一种方式打穿。我习惯先做三件事：查日志看有没有异常请求、用本地环境复现、确认影响范围是单点还是全局。这三步走完，心里才有底。

补丁怎么写也有讲究。有些人喜欢“最小改动”，哪里报错改哪里。比如一个越权漏洞，他就在那个接口加个权限判断。可同样的逻辑在另外三个接口里也有，只是没被扫出来。这种修法叫“打地鼠”，迟早还会出事。我更倾向于顺着漏洞类型去全局搜一遍，把同类模式全找出来。哪怕多花半天时间，也比下周再爆一个强。

还有一点容易被忽略：修复完得验证。不是跑一遍单元测试就完事。单元测试往往覆盖不到边界条件，而漏洞恰恰藏在边界里。我的做法是写一个针对性的利用脚本，在修复前跑通，修复后再跑一次，确认打不穿了。然后把这个脚本加进回归测试集。下次谁再改这块代码，测试会直接拦住他。

最后说个真实教训。有个内部系统修了一个XSS漏洞，前端做了转义，后端也加了过滤。大家觉得万无一失。结果三个月后，有人在另一个完全不相干的页面里，通过一个富文本编辑器又注入了脚本。原因是那个编辑器的白名单配置里，漏掉了一个冷门标签。修复漏洞不是一劳永逸的事，它更像打扫房间——你今天扫干净了，明天还会落灰。关键是养成习惯：每次上线前扫一眼依赖库的CVE列表，每次代码评审多问一句“用户输入处理干净了吗”。

漏洞不会消失，但你可以让它变得没那么容易得手。