凌晨三点，当的我盯着屏幕上的程序输出结果，数字是有b运行对的。但我知道它有病。当的

那是程序一个用Python写的批处理脚本，跑了一晚上，有b运行处理了十二万条日志。当的输出文件里，程序每一条记录都乖乖躺在该在的有b运行位置，格式整齐，当的字段完整。程序可我清楚，有b运行中间有个地方逻辑写反了——判断条件里本该用 and，当的我手滑敲成了 or。程序按理说，有b运行这个错误应该导致大量脏数据涌入结果集。但没有。数据干净得像刚洗过的盘子。

我翻回去看代码，反复确认那个 or 确实在那儿。然后我意识到发生了什么：上游数据源本身就带着一层过滤，所有不满足条件的记录在进入我的脚本之前就被拦掉了。我的bug被另一个系统的“善意”给兜住了。它像一个走路瘸腿的人，恰好踩在一条平坦的传送带上，看起来走得比谁都稳。

这种事在开发里太常见了。你写了个循环，边界条件写错了，应该 <= 写成了 <。但数组长度恰好是奇数，循环少跑一轮刚好避开了那个会触发崩溃的索引。程序跑完了，结果“看起来”没问题。你盯着它，心里发毛，像看着一个发烧但还在笑的小孩。

更麻烦的是，这种bug会传染。团队里有人发现这段代码能跑，就把它复制到另一个模块。新模块的数据源没有那层上游过滤，于是bug突然发作，线上报警响了。你回去查，发现最初那个“能跑”的版本还在跑，还在输出正确结果。你改还是不改？改了，当前业务可能因为数据源的特殊性反而出错；不改，下一个复制它的人会踩进同一个坑。

我见过一个最离谱的例子。一个Java服务里有个空指针异常被 try-catch 吞掉了，catch块里只打了一行日志，没做任何处理。这个服务跑了两年，没人发现。因为触发那个空指针的条件极其苛刻：需要用户ID为null，同时请求头里带一个特定版本的客户端标识，而且那个请求必须落在某个特定时间窗口内。两年里，这个条件组合只出现过三次。每次出现，服务都静默地返回了一个空对象给前端，前端把空对象渲染成空白页，用户以为网络卡了，刷新一下就好了。

直到某天，一个测试同学用自动化脚本批量请求，恰好模拟出了那个组合。服务开始疯狂报错，日志刷了几百兆。开发团队连夜排查，最后定位到那个两年前的catch块。修完之后，有人问：那之前那三次空白页，算不算事故？没人能回答。

所以当你发现一个bug但程序还能跑的时候，别急着庆幸。先问自己三个问题：是数据救了它，还是调用方救了它，还是运气救了它？如果是数据，数据会变。如果是调用方，调用方会改。如果是运气——运气总有用完的时候。

我最后的做法是，把那个 or 改回 and，然后手动构造了一批不满足上游过滤条件的数据，重新跑了一遍。输出果然脏了。但这次我知道它为什么脏，也知道它会在什么时候脏。这比一个“能跑”的bug让人踏实得多。

程序能跑，和程序正确，中间隔着一整个太平洋。