```html

修改漏洞

凌晨两点十七分，告警群又炸了。修改漏洞

不是修改漏洞那种“服务重启一下就好”的常规抖动。这次是修改漏洞支付网关的verifySign接口在特定参数下返回了true——本该返回false的。我盯着日志里那条请求，修改漏洞orderId后面跟了一串精心构造的修改漏洞Unicode字符，肉眼几乎看不出和正常订单号的修改漏洞区别。签名验证被绕过了。修改漏洞

这就是修改漏洞漏洞。它不跟你讲道理，修改漏洞也不管你写了多少行单元测试。修改漏洞它就在那里，修改漏洞像地板缝里的修改漏洞一根针，平时踩不到，修改漏洞踩到了就是修改漏洞一脚血。

我见过太多人把“修漏洞”和“打补丁”混为一谈。补丁是止痛药，漏洞是病根。你给if加个else，给参数加个正则过滤，看似堵上了，可下个月换个入口，同样的逻辑缺陷又冒出来。真正的修改，得回到代码最初被写下的那个瞬间——写它的人当时在想什么？为什么漏掉了这个分支？

去年有个案例我印象很深。一个内部管理后台的越权漏洞，普通用户能通过修改URL里的userId查看别人的工资条。修复方案很“标准”：在控制器里加一行if (currentUser.id != targetUserId) throw new ForbiddenException()。代码合并了，测试通过了，上线了。三个月后，同样的越权出现在导出接口上。因为导出功能是另一个团队后来加的，他们复制了旧的控制器模板，漏掉了那行判断。

所以修改漏洞这件事，最忌讳的就是“就事论事”。你得往上抽一层，找到那个让错误反复发生的模式。是权限校验散落在各个控制器里？那就抽成拦截器或者注解。是输入验证依赖开发者手动调用？那就用框架层的参数绑定自动完成。是业务逻辑和鉴权耦合太深？那就把鉴权提到网关层。

“修一个漏洞，要顺手把同类漏洞的滋生土壤铲掉。不然你就是个救火队员，今天灭东边，明天西边又着了。”

但这话说起来轻巧。现实里，你往往没时间做重构。线上还在流血，老板在群里@你，运营在催恢复。你只能先打补丁，把userId判断加上，把那个Unicode字符过滤掉。然后呢？然后你得记着，这地方欠了一笔技术债。下次迭代排期，把它还上。

我自己的习惯是，每修完一个漏洞，在代码注释里留一行// FIXME: 此处校验逻辑应上移至XXX，见JIRA-1234。不写“修复了XXX漏洞”，那种注释三个月后没人看得懂。要写清楚为什么这么修是临时的，什么才是长久方案。代码是写给下一个接手的人看的，而那个人很可能就是三个月后的你自己。

还有个坑：别迷信自动化扫描工具。SonarQube、Fortify这些能帮你发现已知模式的缺陷，但业务逻辑漏洞它们基本无能为力。比如“用户A能取消用户B的订单”这种，工具怎么知道你的业务规则里取消操作应该限定在本人？它只能检查你有没有做权限判断，没法检查你判断得对不对。所以人工代码审计永远省不掉，尤其是核心链路。

说到核心链路，修改漏洞时最怕的就是“修出新漏洞”。你加了个过滤规则，结果把正常用户的合法请求也拦了。你改了个校验顺序，结果并发场景下出现了死锁。这种案例我见得太多。所以每次改完，除了跑单元测试，我一定手动构造几组边界数据：空值、超长字符串、特殊字符、并发请求。别嫌麻烦，线上事故的代价比这大得多。

最后说个观察。很多团队修漏洞，修完就完了，不写复盘，不更新文档，不补充测试用例。结果半年后新人入职，同样的坑再踩一遍。我现在的做法是，每个漏洞修复必须附带一个regression test，而且这个测试要能复现原始漏洞场景。这样下次谁不小心改回去了，CI直接挂掉。测试用例本身就是最好的文档——它用代码描述了“什么情况下会出问题”。

凌晨四点，补丁上线了。我关掉告警群，在笔记本上写下：verifySign的Unicode归一化问题，根因是签名前未对参数做规范化处理。临时方案已过滤，长期方案是引入统一的参数预处理层。 然后合上电脑。明天还得继续改。

---

漏洞永远改不完。但每次修改，你都能让系统比昨天结实一点。这就够了。

```