软件BUG
软件BUG
凌晨三点十七分，我盯着屏幕上一行红色的软件报错信息，手指悬在键盘上方，软件迟迟没有敲下去。软件那是软件一个空指针异常，出现在用户点击“保存”按钮之后。软件逻辑上不可能——我明明在方法入口做了判空。软件但日志不会撒谎，软件堆栈信息清清楚楚地指向了第247行。软件
这就是软件BUG。它不跟你讲道理，软件不遵守你的软件设计文档，甚至不尊重你写了十年的软件代码直觉。它就在那里，软件像一颗埋在地基里的软件螺丝钉，平时悄无声息，等到某个特定的操作序列、某个罕见的并发时序、某个用户输入了带全角空格的字符串时，“砰”，整个页面白了。
我见过最离谱的一个BUG，发生在一套财务系统里。每到月末最后一天，报表金额总会少三分钱。开发团队查了三个月，从数据库精度查到浮点运算，最后发现是某位同事在计算税额时用了Math.round()，而那个值恰好是2.5。Java的round对.5的处理是向偶数舍入，于是2.5变成了2，3.5变成了4。三分钱，够买什么？但它让一个上市公司在季度审计时被质询了整整两天。
public double calculateTax(double amount) {
return Math.round(amount * 0.13 * 100) / 100.0;
}
// amount = 19.23 时，结果是多少？
BUG的种类千奇百怪。有些是逻辑错误，比如把&&写成了||；有些是边界问题，数组越界、整数溢出、空集合遍历；还有些纯粹是环境差异——开发机上是JDK 8，生产环境是JDK 11，某个废弃的API在半夜偷偷改了行为。更别提那些因为网络延迟、时钟漂移、磁盘写满导致的“幽灵BUG”，你重启一次就再也复现不了，但它确实在监控系统里留下了一条刺眼的红色曲线。
我有个朋友在游戏公司做后端。他们上线了一个新副本，玩家反馈说BOSS在血量低于10%时会突然满血。查了一周，发现是某个技能的回调函数里，if (hp < 0.1 * maxHp)写成了if (hp = 0.1 * maxHp)。赋值当判断，C语言的老陷阱。他说那行代码是复制粘贴来的，编译器只给了个警告，没人注意。上线后，那个BOSS成了全服最著名的“不死小强”，玩家甚至还给它编了段子。
“这不是BUG，这是特性。”——每个被逼到绝境的开发者都说过这句话。
但说实话，没有BUG的软件是不存在的。代码是人写的，人就会犯错。复杂的系统里，组件之间的交互路径呈指数级增长，你不可能穷举所有可能性。测试能覆盖80%的场景，剩下20%就是BUG的温床。有些BUG无伤大雅，比如按钮文字错位了两个像素；有些则能要命——1996年阿丽亚娜5号火箭爆炸，就是因为一个64位浮点数转16位整数时溢出；2020年某交易所宕机四小时，起因是一行if (order.getPrice() > 0)忘了处理null。
我现在的习惯是：写完任何一段代码，先问自己三个问题——输入为空会怎样？数值到了边界会怎样？并发调用会怎样？这三个问题能挡掉一大半的低级BUG。剩下的，靠日志、靠监控、靠用户反馈。有一次用户跟我说“页面偶尔会闪一下”，我查了三天，最后发现是某个异步请求返回后触发了两次重绘。这种BUG，你不把用户当人肉传感器，根本发现不了。
凌晨四点零二分，我终于找到了那个空指针的源头。是一个缓存穿透的场景：用户查询一个不存在的ID，缓存返回了null，而我的判空逻辑写在了缓存读取之后。改完，提交，合上电脑。窗外有鸟开始叫了。
BUG不会消失。明天还会有新的。但至少今晚，这个该死的空指针不会再让任何人看到那个红色的错误页了。这大概就是写代码的某种意义——你永远在跟自己的疏忽和世界的复杂性搏斗，偶尔赢一局，然后继续下一局。
```