凌晨三点，查找我盯着屏幕上那条报错日志，问题咖啡已经凉透了。漏洞系统在用户点击“确认支付”后偶尔会跳回购物车，查找概率大约百分之二。问题测试环境复现不了，漏洞生产环境偶发，查找最要命的问题是——财务对账时发现，有几笔订单金额和实际扣款差了0.01元。漏洞

0.01元，查找不是问题四舍五入的问题。我翻遍了支付回调的漏洞代码，每一行都像是查找正确的。直到我把目光从代码逻辑上移开，问题去看数据库表结构，漏洞才发现那个`order_amount`字段是`DECIMAL(10,2)`，而前端传过来的却是`FLOAT`类型。浮点数在二进制里根本表示不干净，0.1加0.2等于0.30000000000000004，这玩意儿在特定精度转换下就多出那么一丁点。测试环境的数据量小，碰巧没触发；生产环境订单多了，总有几个数字踩中那个二进制陷阱。

这让我想起上个月处理的一个线上故障。用户反馈说上传的图片偶尔会旋转90度，不是所有手机都这样，只有部分安卓机型。排查了整整两天，最后发现是Exif信息里的方向字段，有些国产ROM写入了非标准值——标准的1到8之外，出现了9。图片库遇到9就直接当成0处理，而0在某种解码器里意味着“不旋转”，在另一种解码器里却意味着“旋转90度”。没有一个人写错代码，但两个库对同一个非法值的解释不同，碰撞出了这个bug。

找漏洞这事儿，最坑人的往往不是那些明显的逻辑错误。那种`if`写反了、循环少了个`break`的，一眼就能揪出来。真正折磨人的，是藏在类型边界、隐式转换、第三方库的“未定义行为”里的问题。你盯着代码看十遍，每一遍都觉得它是对的，因为它确实“对”了——在你假设的那个世界里对。可现实世界的数据，从来不按你假设的来。

我有个习惯，排查问题的时候会先问一句：“这里有没有什么是我默认它不会发生的？”大多数时候，答案就是漏洞所在。比如那个0.01元，我默认了前端会传字符串，结果它传了浮点数；我默认了数据库会做四舍五入，结果它在存储前就丢了精度。又比如那个图片旋转，我默认了Exif方向值一定在1到8之间，结果厂商就是写了个9进去。

人脑有个毛病，喜欢把复杂的事情简化成几个“理所当然”的规则。写代码的时候，这种简化帮你快速搭起框架；但排查问题的时候，这种简化就是最大的敌人。你得逼着自己去怀疑那些“不可能出错”的地方——不是怀疑代码逻辑本身，而是怀疑你心里那个“它一定是这样工作”的假设。

上周我把那个支付bug的修复方案提交上去，只改了一行——把前端传参强制转成字符串再解析。同事问我怎么发现的，我说：“因为我终于承认，我控制不了别人会往接口里传什么。”他笑了，说这不像是个技术答案，倒像是个哲学答案。

也许吧。但排查问题的时间越长，我越觉得，大部分漏洞都不是代码写错了，而是我们对“数据长什么样”的想象太干净了。生产环境的数据是脏的、乱的、带着各种历史包袱的。你代码写得再漂亮，只要对数据的假设错了一个，那漂亮就是个摆设。

现在我把这条经验贴在显示器边上：“永远不要相信输入，包括你同事的输入，包括你上个月自己的输入。”这话糙了点，但管用。毕竟，代码不会骗人，骗人的是我们对它的一厢情愿。