上周三凌晨两点十七分，弥补我盯着屏幕上那条报错日志，技术咖啡杯沿的漏洞褐色痕迹已经干成了地图。系统又崩了，弥补这次是技术支付回调的签名校验漏了个边界条件。不是漏洞第一次了，上个月同样的弥补位置，只是技术换了种触发方式。

技术债这东西像厨房下水道里的漏洞油垢，平时看不见，弥补等堵了才意识到日积月累的技术黏腻。我们的漏洞代码库里躺着三年前的临时补丁，当时写注释说"下个迭代重写"，弥补现在那个迭代的技术迭代都上线无数回了。没人愿意碰那段逻辑，漏洞像没人愿意清理冰箱冷冻层结的厚霜。

但这次我不想再打补丁了。凌晨的办公室特别安静，空调嗡嗡的底噪里，我把那个函数的调用链整个拉出来看。从网关到服务层到数据访问，十二个模块互相甩锅，最后发现是两套加密库对空值的处理方式不一致。A库返回空字符串，B库返回null，中间层的比较逻辑只判断了其中之一。

修复本身只花了四十分钟，加了个统一转换的适配器。真正耗时间的，是梳理清楚为什么会出现这种不一致——因为半年前某个同事为了赶上线，直接调了新库的接口，没跑旧的回归测试。他当时觉得"应该没问题"，这个"应该"变成了定时炸弹。

我后来在团队周会上提了个规则：每次修复漏洞，必须写清楚根因和预防措施，贴在项目看板上。有人觉得小题大做，说这种低级错误记下来丢人。但第二周，隔壁组就遇到了几乎一样的坑——他们读了我贴的卡片，十分钟就定位了问题。

漏洞本身不可怕，可怕的是每次都用创可贴止血，却从不问血为什么流。我把那个支付模块的测试用例从23个加到87个，覆盖了所有已知的边界情况。新增的用例里有一条，专门模拟上游返回异常编码的情况——就是凌晨两点十七分那个场景。

代码跑通的时候天已经亮了，早班地铁的报站声从窗户缝里渗进来。我盯着屏幕上绿色的测试通过标志，突然觉得技术工作最大的成就感不是写了多少新功能，而是把那些摇摇欲坠的地方真正焊死。漏洞弥补的意义不在于修复本身，而在于你终于理解了系统为什么会漏。

现在那个模块已经稳定运行了两个月，但我知道下一个漏洞肯定在别处等着。没关系，这次我学会了先看数据流经的每一道闸门，而不是急着堵眼前的缺口。毕竟下水道要通，光靠疏通是不够的，得让油脂不再凝固成块。