场景一：

以前跟表哥一起去修车，我们的车的空调坏了。这时候一个师傅听我们叙述后，就直接对空调作了检查。检查了许久，没发现毛病。

然后又一个师傅路过，修空调的师傅就叫他一起看看，那师傅说先检查保险丝。结果..果然是保险丝断了。

在我看来很诧异，第一个师傅年龄上要大些，理论上应该经验更丰富，后一个师傅就是一个年轻小伙子。这个小伙子居然能一眼看出毛病所在。我想这小伙子肯定经过专业的培训…

场景二：

一php程序出问题了，结果出不来。然后我自以为对程序熟，就在程序里加断点调试啊调试啊，终于被我debug出问题了，运行时语法错误。自己回想，这tm去php语法错误日志里面看看不就知道了么？

场景三：

一哥们儿程序在开发环境没问题，部署到线上时出问题了。通过不懈的努力，有些怀疑是构建工具有问题，但不太确定，毕竟构建工具出问题情况比较少，基本都是自己业务代码有问题。中间还看diff，看是否改错代码了。最后实在捉急上线，就请教了别人。这个帮助我的哥们儿，也不确定，建议改下构建工具脚本，尝试下。结果。。。尼玛，就是构建有问题。问题来了，我tm为何不去看构建日志？最后去构建日志一看，果然，报错了。

总结

去检查一个bug时，首先要看的应该是“各种阶段”的“仪表盘”，比如构建日志，语法日志，保险丝等等。而不是盲目地去怀疑自己的逻辑出错。