凌晨两点十七分，我盯着屏幕上那行报错代码，咖啡杯沿凝着褐色的渍迹。这是第三次尝试修复同一个bug了——用户上传图片时偶尔会触发500错误，但本地环境完全复现不出来。我甚至怀疑过是用户网络问题，直到翻到日志里那条被截断的二进制流。

那个字节数组在第2048位突然变成了负数。Java的byte类型是有符号的，一旦超过127就会溢出。可上传模块明明做了类型转换，怎么会漏掉这里？我翻到三个月前重构的代码，注释写着“优化内存占用”，把原本的int数组改成了byte数组。就是那次优化埋的雷——图片的EXIF信息里藏着某些特殊字符，恰好会让校验位溢出。

修复的办法倒是简单，把那个判断条件从“大于0”改成“不等于0”就行。但真正让我后背发凉的是，这个bug已经在生产环境跑了87天，影响了几百个用户。没人报障，因为错误提示被前端吞掉了，用户只看到“上传失败，请重试”，大多数人试两次就放弃了。

这让我想起上周修另一个bug的经历。用户反馈说夜间模式下按钮看不见，我调了半天样式，最后发现是某次CSS变量重命名时漏改了一处引用。全局搜索“--primary-color”，新旧变量名混着用，浏览器静默地忽略了不存在的变量，直接套用默认值——而默认值恰好是白色。

写代码这事，有时候就像在雷区里绣花。你永远不知道哪次“顺手优化”会踩中什么。我记得刚入行时带我的师傅说过一句话：“bug不是写出来的，是改出来的。”当时觉得他迂腐，现在想想，每个看似无关紧要的改动，都可能在某个角落引发连锁反应。那个把int改byte的新人，大概也觉得自己在做性能优化吧。

不过说真的，修bug最磨人的不是技术难点，而是那种“明明很简单却找不到”的挫败感。有次我为了查一个偶发的空指针，硬是把整个服务端框架的源码读了一遍，最后发现是某个第三方库在特定JDK版本下的已知问题——升级版本就好。那种感觉就像你翻遍整个房间找钥匙，最后发现钥匙就插在门上。

凌晨三点，我终于把修复补丁提交了。CI跑完测试，全绿。我关掉IDE，屏幕暗下去的那一刻，看到自己映在黑色玻璃里的脸，眼袋重得能装下整个项目的技术债。窗外有鸟叫了，新的一天开始，而昨晚那个bug已经成了历史。但我知道，代码库里还藏着无数个类似的陷阱，等着某个深夜被谁一脚踩中。