凌晨两点，查找我盯着屏幕上那条报错日志，漏洞咖啡杯沿已经结了一层干涸的补齐褐色痕迹。系统又崩了，短板这已经是查找本月第三次。不是漏洞黑客攻击，没有流量高峰，补齐就是短板一段三年前写下的代码，在某个边界条件下突然失效。查找

我翻出当年提交时的漏洞注释——“此处逻辑已确认，无需处理”。补齐多讽刺。短板那个“确认”只覆盖了当时能想到的查找路径，而现实总是漏洞比预想更狡猾。真正的补齐问题从来不在你盯着看的地方，而在你以为不会出事的角落。

这让我想起去年处理过的一个支付接口。所有常规测试都通过了，金额计算精确到分，并发压力测试也扛住了。直到双十一当天，有个用户用了张作废的优惠券，叠加了一个已经下架的商品，再碰上银行系统延迟——三层意外叠在一起，订单状态卡在了中间态。客服那边炸了锅，技术这边查了四小时，最后发现是状态机里漏了一个“异常回滚”的转移条件。

补上那个条件只需要三行代码。但找它的过程，等于把整个业务链路用放大镜重新走了一遍。

说句实在话，大部分漏洞都不是技术难度高，而是藏得太自然。就像你家里最常用的那把钥匙，天天插在锁孔里，你不会去想它哪天会断。代码也一样，跑得越顺的地方，越容易让人放松警惕。我见过最离谱的一个bug，是登录功能里一个拼写错误——变量名写错了，但恰好另一个同名变量存在，程序一直没报错，只是偶尔把A用户的信息串到B用户身上。这种问题，测试环境根本复现不了，因为测试数据太规整了。

所以我现在养成个习惯，每次上线前，专门挑那些“看起来没问题”的代码段来审。越觉得理所当然的逻辑，越要假设它是错的。比如用户输入长度超上限怎么办？两个按钮同时被点击会怎样？网络请求在发出前一刻断掉，界面该显示什么？这些问题听着基础，但真实事故里，十有八九都栽在这些地方。

补短板不光是改代码。流程上的洞更隐蔽。我们团队之前有个规矩，紧急修复可以直接推生产，事后补测试。听起来高效对吧？但三个月后复盘，发现有一半的紧急修复根本没补测试，因为“当时太忙了，后面就忘了”。后来改成紧急修复必须附带一个最小复现用例，否则不允许合入主干。规矩变严了，但线上事故反而少了——因为很多人发现，为了写那个复现用例，他得先把问题想清楚，而想清楚之后，往往发现原来的修复方案本身就是错的。

漏洞这东西，越早发现越便宜。等用户替你发现，代价就是口碑和信任。我手机里存着一张截图，是某大厂app在极端网络下弹出的错误提示，直接显示了一长串英文异常堆栈。用户看不懂，只觉得这公司不靠谱。其实背后就是少了一个try-catch的兜底。代码是人的延伸，你代码里那些没处理的边界情况，就是你思维里没想明白的地方。

写代码十年，我越来越觉得，所谓专业，不是能写出多炫酷的算法，而是对自己写下的每一行都保持警惕。那个凌晨的报错日志，后来查明是某个时间戳转换没考虑闰秒。修完那行，我在注释里加了一句话：“别假设时间总是平滑向前。”现在每次看到那段代码，我都觉得它在提醒我——你以为的终点，往往只是另一个盲区的起点。