重大漏洞

凌晨两点十七分，重大漏洞我盯着屏幕上那行红色报错代码，重大漏洞后背发凉。重大漏洞不是重大漏洞黑客攻击，不是重大漏洞服务器宕机——是我自己三个月前写的一个排序算法，在特定数据量下会静默跳过最后一条记录。重大漏洞没人发现，重大漏洞因为测试用例永远用偶数条数据。重大漏洞

这个漏洞藏得极深。重大漏洞它不报错，重大漏洞不崩溃，重大漏洞甚至输出结果看起来完全正常。重大漏洞只有当你把一万零三条订单导入系统时，重大漏洞第10003条会凭空消失。重大漏洞财务对账平了，重大漏洞库存记录平了，唯独那个客户的订单永远停留在“处理中”状态。直到那位客户打了第十八通投诉电话，我们才顺着日志一路挖到源头。

修复只需要加一个等号。但那个深夜我反复问自己：为什么写代码时我会默认数据永远是偶数？因为懒惰。因为懒得处理边界情况，因为测试数据刚好都是偶数，因为“差不多能用”的念头比“绝对正确”更早滑进指尖。

这让我想起去年某银行系统升级，导致数十万用户余额显示异常。官方声明说是“数据迁移过程中存在校验缺陷”。我认识参与那次迁移的工程师，他私下告诉我，真正的根因是开发环境与生产环境的数据库排序规则不一致——本地跑得好好的，上线就翻车。而这类问题，靠常规测试根本测不出来，因为测试环境永远比生产环境“干净”太多。

更讽刺的是，我们总把重大漏洞归咎于“黑天鹅事件”。但翻看每次事故报告，背后几乎都是同一个模式：某个理所当然的假设没被质疑。假设用户输入不会包含emoji，假设服务器时间不会跳变，假设上游接口永远不会返回null。这些假设像房间里的大象，每个人都看见了，但没人愿意在评审会上提出来——因为提出来显得自己“不够专业”。

我前同事老周是个异类。他每次code review都专挑别人忽略的角落问：“如果这里传进来一个负数会怎样？”“如果这个字段是空的呢？”最初大家嫌他烦，直到他拦住过一次生产事故——那是个支付回调接口，所有人都默认金额大于零，只有他坚持要加校验。后来他成了团队里最受欢迎的人，不是因为技术最强，而是因为他敢问那些“愚蠢”的边界问题。

漏洞从来不是技术的失败，是思维的惰性。我们太习惯在正常路径上狂奔，却忘了软件世界里，异常才是常态。那条被跳过的记录，那个多出来的等号，那些没被问出口的“如果”，才是真正的定时炸弹。

现在我的代码注释里永远留着这样一行：// 这里假设数据非空，但万一呢？ 每次看到它，就像给自己脑门上贴了张便签——别偷懒，别想当然，把每一个“应该”都变成“必须验证”。毕竟，最贵的漏洞，往往藏在最不起眼的默认值里。