😂 IT段子

bug 的优先级取决于谁发现了它。我默默记下了这句话。我把这个函数的入参和出参都打了，发现中间少了一层转换。好在最后有惊无险

问题居然复现不了了，这比复现出来更可怕。我忽然觉得，这可能就是这一行的常态。我发现这个接口在特定参数组合下返回了空对象。这大概就是程序员的人生吧

调试到后面会发现，最大的敌人是自己的假设。我抬起头看了看周围，大家都一样。我在本地把这段代码跑了一千遍，一次都没复现。这条经验值直接拉满

这个问题的根因是我三个月前的一个「临时方案」。我听完沉默了，因为太真实了。我发现是并发导致的，单线程下它一直是好的

线上日志里出现了从未见过的堆栈，时间戳还是三个月前的。我拉了个小群，把相关同学都叫了进来。我发现是序列化的问题，字段名大小写在两端口径不同。真香定律准时生效

调试最花时间的不是修，是确认自己修的是对的地方。我忽然觉得，这可能就是这一行的常态。我把这个死循环的跳出条件补上了，进程终于不卡了。感动，然后我学到了新的一课

print 调试大法永远的神，断点还没配好，print 已经输出三轮了。我叹了口气，然后打开了编辑器。我在心里给这个 bug 取了个名字，叫「薛定谔的报错」。复盘会上我们把它列成了案例

我第一时间把锅甩给了缓存，结果真的是缓存。我默默打开了编辑器，准备一步步验证。我发现问题出在一个我以为永远不会被触发的分支里。办公室安静得能听见键盘声

print 调试大法永远的神，断点还没配好，print 已经输出三轮了。我笑了笑，决定不解释。我把这个问题的复现概率测了一下，大概百分之三。第二天这个方案就变成了团队标准做法

加了二十行 console.log 之后，Bug 消失了，删除它们，Bug 又回来了。我打开记录从头到尾扫了一遍。我把复现步骤记了满满一页，下次再遇到至少能快一点。那一刻我觉得自己还是很专业的