上周三凌晨两点，漏洞运维群里弹出一条告警：某业务系统的整改订单查询接口响应时间从200毫秒飙到4.7秒。值班同事重启了服务，情况暂时压住了问题，说明但根因没找到。漏洞第二天排查发现，整改是情况一个月前上线的“优惠券批量发放”功能留下的坑——那段代码在循环里反复查数据库，每次查询都带上了全表扫描。说明数据量小的漏洞时候看不出毛病，等优惠券表累积到八十多万行，整改直接拖垮了整条链路。情况

这不是说明孤例。过去半年我跟进的漏洞十几个漏洞整改案例里，有七成以上都源于“当时能跑就行”的整改临时方案。比如某个内部管理后台，情况开发为了赶进度，把用户权限校验写在了前端JavaScript里。后端接口只检查了token有效性，没校验角色。任何人抓包改一下请求参数，就能以管理员身份删除数据。这个漏洞在测试环境没暴露，因为测试账号恰好都有管理员权限。上线三个月后，一个离职员工用旧账号登录，意外发现了这个口子。

整改这类问题，第一步不是急着改代码。得先搞清楚漏洞的触发条件和影响范围。上面那个权限漏洞，我们花了半天时间梳理所有接口的鉴权逻辑，发现除了删除操作，还有三个导出接口同样没做角色校验。如果只修删除那一个点，等于给门上了锁却留着窗户。具体做法是拉出一份完整的接口清单，逐个标注“前端校验/后端校验/无校验”，再按业务敏感度排优先级。这个过程很枯燥，但省不掉。

第二步是确定修复方案。有些团队喜欢直接打补丁——哪里报错改哪里。短期有效，长期会积累更多技术债。那个订单查询的慢SQL问题，最初有人提议加个缓存了事。但缓存会带来数据一致性问题，优惠券的剩余数量必须实时准确。后来我们改了查询逻辑，把循环查库改成一次批量查询，再给优惠券表的“活动ID+用户ID”建了联合索引。响应时间回到180毫秒，数据库CPU也从90%降到35%。改动不大，但需要理解业务语义，不是单纯调优能解决的。

修复之后的验证环节最容易走过场。我见过一个团队改了文件上传漏洞的过滤规则，测试时只传了.jpg和.png，都通过了，就认为修好了。结果漏掉了.svg文件——里面可以嵌入JavaScript。正确的做法是构造畸形输入：改扩展名、改MIME类型、在文件名里加特殊字符、上传超大文件、上传压缩包。每次整改后，我都会让测试同学按这个清单跑一遍，至少覆盖OWASP Top 10里的相关场景。

还有一点常被忽略：整改记录要写清楚“为什么这么改”。三个月后新人接手，看到代码里一段奇怪的判断逻辑，很可能顺手“优化”掉，漏洞就复活了。我们现在的做法是在关键修复处加注释，格式是“漏洞编号+触发条件+修复原理”。比如“VUL-2024-017：原逻辑未校验文件头，攻击者可上传伪装成图片的脚本。现增加magic number检查，仅允许JPEG/PNG。”这样后来者能看懂，不会误删。

最后说个观察：漏洞整改的完成标准不是“代码合并了”，而是“攻击路径被切断且不影响正常业务”。上个月有个XSS漏洞，开发把用户输入里的<script>替换成了空字符串。看似修好了，但用户输入“<scr