去年冬天，系统某电商平台的漏洞一次大促活动中，订单系统突然出现诡异的复方法重复扣款。用户点击一次支付，系统后台却生成了三笔订单。漏洞技术团队排查了六个小时，复方法最后发现问题出在一段两年前写的系统优惠券核销代码上——那段代码在处理并发请求时，没有对同一个用户ID加锁。漏洞一个看似无关紧要的复方法疏忽，在流量峰值时被放大成了数百万的系统资损风险。

漏洞从来不是漏洞“突然出现”的。它一直在那里，复方法只是系统等待一个合适的触发条件。修复漏洞的漏洞第一步，不是复方法急着打开代码编辑器，而是先搞清楚：这个漏洞为什么现在才暴露？触发它的最小条件是什么？

我见过不少团队一发现bug就立刻改代码，改完上线，结果引出三个新问题。这就像水管漏水，你不先关总闸，直接拿胶带缠，水压一上来照样崩。正确的做法是先复现，再定位，最后才动手。复现意味着你能稳定地让漏洞出现，定位意味着你找到了出问题的具体函数或配置项，动手才有意义。

定位漏洞有个笨办法但很管用：二分法。把系统按调用链路切成两半，判断问题出在前半段还是后半段。比如一个API返回了错误数据，你先看数据库里的原始记录对不对。如果数据库是对的，问题就在业务逻辑层；如果数据库本身就是错的，那往上游的写入环节查。一层层切下去，范围会迅速缩小。我曾经用这个方法在一个十万行的代码库里，四十分钟定位到一个数组越界的索引值。

找到问题代码后，修复方案往往不止一种。这时候要问自己：是打补丁，还是重构？打补丁快，但可能留下技术债；重构彻底，但风险高、周期长。我的判断标准是看这个漏洞的根因类型。如果是边界条件没处理——比如空值、超长字符串、负数——加个校验就行。如果是设计层面的缺陷——比如状态机漏了一个转换路径——那就必须改设计，否则同类漏洞还会从别的入口冒出来。

修复完成不等于结束。上线前至少要做三件事：单元测试覆盖那个漏洞场景、在预发环境用真实流量回放验证、观察上线后24小时的错误日志和核心指标。有一次我们修了一个缓存穿透的漏洞，测试环境一切正常，上线后QPS一高，新的空值缓存策略反而把Redis内存打满了。教训就是：修复本身可能引入新的瓶颈。

还有一点容易被忽略：记录。不是记流水账，而是写清楚漏洞的触发条件、影响范围、修复思路、验证结果。这份记录在半年后有人改同一块代码时，能帮他避开雷区。我习惯在代码注释里留一行简短的标记，比如“2024-03 修复并发核销重复扣款，勿删用户ID锁”。简单，但有用。

说到底，修漏洞跟修车差不多。你得先听异响从哪来，再决定是紧螺丝还是换零件。最怕的是抡起锤子就砸，砸完了发现砸错了地方。系统是人写的，人就会犯错。承认这一点，然后老老实实按流程走——复现、定位、评估、修复、验证、记录——比任何花哨的工具都可靠。