我写代码大部分时间都在找bug，同事说调试本身就是编程思维的体现。我想知道调试时那种层层排查、假设验证的思考方式，算不算编程思维在工作中最真实的表现，以及这种能力怎么有意识提升。
0 赞同
0 回答
当前主题
# 调试
-
-
每次用户报Bug我都没法在自己的环境里复现，日志看了一圈也没找到关键线索。用户那边是中文版系统加特殊网络环境，我这边是标准的英文开发环境。是不是系统区域设置、时区或者语言包的不同导致了这些隐形Bug？我感觉很多问题都和操作系统级别的差异有关但不知道该怎么排查。0 赞同 0 回答 -
程序出错时，如果控制台只有一句模糊的失败提示，就很难知道问题发生在哪。加上日志后，能看到变量值、执行顺序和接口返回，错误像被一点点照亮。日志不会自动修复程序，却能让人更快接近真相。为什么错误日志对调试这么重要？0 赞同 1 回答 -
写功能时可能半小时就写完了，真正让人头大的却是后面几个小时的调试。加日志、打断点、反复运行，每次都以为找到了原因，结果修完又冒出新的问题。功能实现只是第一步，确认它稳定运行反而更难。为什么调试常常比写代码本身更花时间？0 赞同 1 回答 -
写了个功能跑起来发现结果不对，但不知道哪里出了问题。打开代码看了半天没看出名堂，只能到处加console.log打印变量值，打了一堆输出还是找不到原因。花了一上午在猜问题在哪。到底调试代码有没有系统的方法，怎么一步步缩小问题范围定位到具体行，除了打日志还有什么更高效的调试手段？0 赞同 1 回答 -
写一个新功能花了两天，但上线之后修Bug修了一个星期。有些Bug看起来很简单，就是一个变量没初始化、一个边界没考虑到，但找出来要花好几个小时。更可怕的是，修完一个Bug又引出三个新Bug，就像打地鼠一样没完没了。明明写代码的时候觉得自己考虑得很周全了，为什么上线之后还是到处是坑？有没有办法从一开始就写出Bug少的代码？0 赞同 1 回答 -
写一个新功能花了两天，但上线之后修Bug修了一个星期。有些Bug看起来很简单，就是一个变量没初始化、一个边界没考虑到，但找出来要花好几个小时。更可怕的是，修完一个Bug又引出三个新Bug，就像打地鼠一样没完没了。明明写代码的时候觉得自己考虑得很周全了，为什么上线之后还是到处是坑？有没有办法从一开始就写出Bug少的代码？0 赞同 1 回答 -
代码报错后，有时候一行一行检查效率很低，半天都找不到问题。听说有调试工具可以帮助找到错误，但不知道具体怎么用。有没有什么方法能更高效地定位代码错误，调试工具该怎么使用，能让排查问题的速度更快？0 赞同 1 回答 -
代码跑不通报错了，但不知道具体是哪一行哪一部分出了问题。有时候错误信息指向的位置和实际错误的地方不一致，有时候改了一段代码错误又跑到别的地方去了。遇到代码报错，有什么方法能一步步排查，准确定位到真正的问题所在？0 赞同 1 回答 -
写完代码检查了好几遍，感觉逻辑完全没问题，但一运行结果就是错的。找同事来看，一眼就发现问题了。自己看自己的代码，好像总是会被自己的思维惯性影响，看不到错误在哪。为什么自己检查自己的代码很难发现问题，有什么方法能跳出这个思维盲区？0 赞同 1 回答 -
做除法计算，预期结果应该是小数，但每次都是整数。检查了半天代码，逻辑没错，数据也没错。后来才发现是两个整数相除，结果自动取整了。代码不报错，但结果一直不对。数据类型的隐式转换太隐蔽了，怎么才能在写代码的时候就意识到这种问题？0 赞同 1 回答 -
代码结果不对，加了一堆print打印中间值。打印出来看，每个变量在每一步的值都对，但最后结果就是错的。有时候print太多，输出一大堆，反而更看不出问题在哪。print调试到底该怎么用，打印什么内容才有用，怎么组织输出才能快速定位问题？0 赞同 1 回答