如何修复漏洞

修复漏洞，何修本质上不是复漏修代码，是何修修逻辑漏洞背后的思维盲区。我见过太多人拿到报错第一反应是复漏“哪行写错了”，盯着堆栈看了半小时，何修最后发现是复漏上游数据格式变了。

真正有效的何修第一刀，永远是复漏复现。别急着猜，何修先把触发条件钉死。复漏我上周处理一个支付回调丢失的何修问题，测试环境怎么点都正常，复漏一上生产就偶发。何修后来翻日志，复漏发现是何修回调请求里带了个毫秒级时间戳，而签名校验用的缓存是秒级——时间差在测试环境跑太快根本追不上。复现不了的问题，修起来全是玄学。

复现成功之后，别急着改。先问自己三个问题：这个漏洞是数据问题、并发问题、还是状态机问题？如果是数据，看边界；如果是并发，看锁和原子性；如果是状态，看流转路径上有没有跳变。举个典型例子，库存扣减超卖，多半是“先查后改”的竞态，你把查询和更新塞进同一个事务里也没用，得用乐观锁或者Redis原子操作。这种问题，靠肉眼扫代码是扫不出来的，得靠压测和并发模拟。

找到根因，动手改的时候，有个反直觉的规矩：改动越小越好。别顺手重构旁边那段看着不顺眼的代码。我见过有人修一个空指针，顺手把整个工具类重写了，结果引入三个新bug，上线当天回滚。修漏洞要像做外科手术，切口对准病灶，旁边的组织别碰。改完先跑单测，再跑回归，最后压一把极端场景——比如把超时时间设成0.1秒，把并发线程拉到1000，故意制造脏数据。

但这里要说句得罪人的话——很多漏洞根本不该走到“修复”这一步。它们是在设计阶段就埋下的雷。接口文档没定义清楚字段边界，数据库表缺唯一索引，缓存和数据库的一致性方案没设计，这些坑靠后期打补丁，永远在填新坑。我最近看一个老项目，光补丁就打了四十多个，每个补丁都在修前一个补丁引入的副作用。这不是技术问题，这是工程纪律问题。

所以我的习惯是，修完一个漏洞，必须写一段“事故后记”，不是给领导看的，是给自己看的。记清楚触发条件、根因、改动点、验证方法，再记一句“下次怎么避免”。比如那次时间戳问题，后记里写的是：所有涉及时间比较的接口，统一用毫秒级时间戳，禁止混用秒和毫秒。这种记录比代码注释管用，因为它记录的是决策过程，不是结果。

最后说个特别容易被忽略的点——修完漏洞，记得删调试代码。我见过有人为了排查问题，在线上环境加了console.log，结果忘了删，日志量暴涨，直接把磁盘打满。这属于修一个漏洞，造一个事故。改完代码，把调试输出、临时开关、硬编码的测试IP全部清干净，然后跑一遍完整的发布流程。别嫌麻烦，你省的那五分钟，可能换来凌晨三点的oncall。

漏洞这东西，永远修不完。但每修一次，你脑子里就会多一张地图——哪里容易塌方，哪里需要护栏。真正的高手不是不出错，是出错之后，能把这次错误变成系统里的一块加固钢板。下次再遇到类似的坑，你会笑着对它说：哟，老朋友，这次我认识你了。