bug漏洞
凌晨三点十七分，测试组的老周在群里发了一张截图。支付页面显示订单金额为0.01元，商品是一台标价六千多的手机。没人说话，过了半分钟，技术总监回了两个字：停服。
这就是bug。它不跟你讲道理，不挑时间，不管你是不是刚上线十分钟。你以为代码写得严丝合缝，它偏偏从某个你根本没想过的角落里钻出来，像水管里的一根头发，堵不死你，但能让你整晚睡不着。
我见过最离谱的一个bug，跟代码逻辑毫无关系。服务器跑得好好的，每天下午三点准时丢包。运维查了半个月，最后发现是保洁阿姨每天三点打扫机房，拖把碰到网线接口，松了。你说这算谁的锅？代码没错，硬件没错，错的是拖把。但用户不关心这些，他们只知道你的服务挂了。
写代码的人都有一种幻觉，觉得bug是“错误”。其实不是。bug是代码在特定条件下的真实行为，只是这个行为恰好不是你想要的。它忠实地执行了你写的每一行指令，包括那些你写的时候没想清楚的。计算机不撒谎，它只是太听话了。
有个前端朋友跟我讲过一件事。他写了个按钮，点击之后弹窗。测试环境一切正常，上线之后用户反馈说按钮点不动。他查了两天，最后发现是运营在按钮上面盖了一层透明图片，用来做数据埋点。图片挡住了点击事件。运营不知道，产品不知道，他也不知道。三个人的“不知道”叠在一起，就是一个线上事故。
bug最恶心的地方在于，它往往不在你盯着的那块屏幕上。你盯着函数逻辑，它在网络延迟里；你盯着网络延迟，它在数据库索引上；你盯着数据库，它在你三个月前随手改的一个配置项里。找bug就像在黑暗里找一只黑猫，而且这只猫还会跑。
但话说回来，没有bug的代码是不存在的。任何超过一千行的程序，都有bug，区别只是有没有被发现。有些bug一辈子藏在某个分支条件里，永远不触发。有些bug每天准时出现，像打卡上班。你能做的不是消灭bug，而是让bug出现的时候，系统还能撑住，日志还能查到，回滚还能来得及。
老周那张截图最后怎么解决的？查出来是优惠券叠加逻辑写反了，满减和折扣的顺序颠倒，导致金额被反复抵扣。修复用了四十分钟，停服两个小时。第二天复盘会上，没人提拖把的事。
写代码这件事，说到底是在跟自己的疏忽打交道。你聪明，bug比你更聪明。你仔细，bug比你更仔细。它就在那里，等着你眨眼。