bug检查代码

凌晨两点十七分，查代咖啡杯底残留的查代液体已经凉透。我盯着屏幕上那个报错的查代日志，第五百次确认代码逻辑没有问题。查代可它就是查代不工作。这就是查代bug检查最让人抓狂的地方——你越是确信自己对了，它越是查代倔强地给你看红色报错。

后来我学会了一件事：先承认自己可能错了，查代再去看代码。查代不是查代那种敷衍的承认，是查代真心实意地把自己当成头号嫌疑人。因为bug检查的查代第一步，从来不是查代找代码的问题，而是查代找自己思维里的盲区。我见过太多人抱着“我写的查代一定对”的念头，在同一个地方转圈三小时，最后发现是变量名拼错了一个字母。

有一次，前端同事急得满头大汗来找我。他说接口返回的数据明明有值，页面却死活显示不出来。我打开控制台，一眼就看见报错信息里写着“undefined is not an object”。他愣住，说不可能，我明明打印过。我让他再看一眼打印的位置——他把console.log放在了数据请求之前。代码是按顺序执行的，你以为它已经拿到数据的时候，它其实还在等网络响应。这不是技术问题，是时序问题。而时序问题，往往是初学者最容易忽略的坑。

检查bug的时候，我习惯先看报错信息本身。很多人一看到红字就慌，直接跳过报错内容去翻代码。这就像看医生时，不告诉医生哪里疼，只让医生猜。报错信息是代码在跟你说话，它已经告诉你它哪里不舒服了。有时候它说“Cannot read property of null”，那你就要去找那个可能为null的对象；有时候它说“SyntaxError”，那你就要在指定行附近找语法问题。别跟报错信息对抗，顺着它走，通常比你自己瞎猜快得多。

但报错信息也不总是靠谱。有些bug是静默的，代码不报错，运行也正常，就是结果不对。这种最恶心人。我遇到过一回，一个排序算法，数组长度小于十的时候一切正常，超过十就乱序。排查了半天，发现是算法里有个边界条件写错了，导致某些情况下的比较次数不够。这种bug藏得很深，你光靠逻辑推演很难发现，最好的办法就是加日志，把每一步的中间结果打出来，肉眼盯着数据流走一遍。

加日志也有讲究。不要一次性加一堆printf，然后看花眼。先加关键节点，比如循环开始前、循环结束后、条件分支的两端。跑一遍，看数据在哪一步开始不对劲，然后缩小范围，再加细粒度的日志。这个过程有点像排查漏水的水管——先确定是哪一段墙里的管子漏，再砸墙，而不是上来就把整面墙拆了。

还有一个容易被忽略的点：环境差异。本地跑得好好的，部署到服务器就挂了。这种问题八成是环境变量、依赖版本或者操作系统差异造成的。我吃过一次亏，代码里用了某个第三方库的新特性，本地node版本高，没问题，服务器上node版本老，直接报错。后来我学乖了，每次部署前先检查一下目标环境的版本信息，别想当然。

最后说个玄学但真实存在的现象：有时候bug会自己消失。你什么都没改，刷新一下就好了。这种时候别高兴太早，也别轻易放过。它消失是因为某个条件碰巧满足了，不代表问题根除了。你要是就这么算了，它大概率会在某一天突然冒出来，而且是在你最忙的时候。最好的做法是记录下当时的环境和操作步骤，试着复现一次。复现不了，至少要写个备注，免得下次再踩坑。

检查bug，说到底是一场跟自己的较劲。代码是死的，人是活的。你的经验、情绪、疲劳程度，都会影响你排查的效率。累了就起来走走，别死磕。很多次我都是去接杯水回来，突然就想通了问题出在哪。脑子需要休息，但你的代码不会跑掉。

天亮的时候，我终于找到了那个bug——一个循环里用了全局变量，导致多线程环境下数据被覆盖。改掉那一行，程序跑通了。屏幕上滚动的日志像水流一样顺畅。我靠在椅背上，咖啡已经彻底凉了，但心里是热的。