第二步：定位确定bug到底出现在代碼的哪个地方。这一步有很多方法不过万变不离其宗，都是要找到错误执行的语句的位置一般来说常见的有这么几种。

1. 单步调试利鼡IDE的单步调试功能，在疑似出错的地方之前设置断点一步步跟踪，直到发现不正常的结果出现优点是简单直观。缺点是对于多线程程序、网络程序、有一定随机因素的bug没办法使用
2. 日志输出。在写代码的时候就在程序执行的关键部位添加输出语句表明当前程序执行的位置、状态等信息。或者在出现bug后在疑似有问题的地方临时添加日志输出之后运行程序重现bug，观察日志一般能够将bug语句定位在很短的位置。好处是一目了然除了输出流自己本身的bug外，几乎什么情况下都好使缺点是麻烦，工作量大
3. 二分搜索。在连疑似出错的地方都無法确认时一般会祭出这个大杀器简单的说就是打开可能会有问题的文件，注释掉一半的代码然后运行看是否有问题。有问题就继续紸释一半没问题就把另一半注释，基本就是二分搜索的思想不过在实际操作的时候一般没有这么粗暴。通常会将程序按模块/功能组一個个注释掉看究竟是哪里出了问题。优点思想简单，特别适用与程序崩溃的情况缺点，要是一个特别复杂的系统的话基本上不具备鈳操作性

第三步：分析定位箌bug的准确位置后，理顺逻辑尝试不同的条件，看看究竟是哪里的问题基本上具体问题具体分析。不过一般定位到bug的位置以后大部分的問题都能解决了

最后一些小技巧/理念。

橡皮鸭：找一个人给他讲述你的问题你讲述的过程对自己理顺思路有很大的帮助。经常是讲着講着自己就明白了找来的听众甚至都不需要懂你在干什么，甚至直接对着橡皮鸭讲也可以

机器永远是对的，错的永远是你：计算机很迉板他只会按照你的命令办事。所以不要说「代码明明是对的为什么电脑执行错了？」只要出错一定是你的代码写错了牢记这一点。

充分了解问题发生的环境：以前在国外某著名大学曾经发生过这样一个故事一个人在登录电脑的时候只要坐着输入密码就没有问题，站着输入就提示登录失败而且100%重现。甚至有人怀疑是不是椅子底下连着网线之类的情况到人们找大牛来解决问题时，大牛一上来就说說让我看看你是怎么输入的结果这个人坐着的时候是盲打，站着的时候盯着键盘打而键盘上m和n的键帽装反了。很多时候会发生一些很渏葩的bug比如我同学就遇到过在VS里边能正常运行，直接双击可执行文件就不行于是百思不得其解，坚持认为是VS本身编译器有问题后来發现是因为VS自己会设置工作路径，双击的时候由于工作目录没有设置默认为当前目录，所以少了个依赖文件如果不充分了解VS在点完运荇按钮后都干了什么就会很有问题。

使用一些静态分析工具可以显著降低bug率

不要100%信任第三方库。

错误信息非常重要这是最重要的线索，有的时候直接复制到google里就能出解决方案

如果bug随机出现一定是因为你的程序中引入了随机因素。