写代码时，通常要耗费大量的时间去排查bug产生的原因，如何快速的定位bug，在很大程度上决定了你的开发效率。下面是我的一些经验分享。
提高编码质量
在一个项目足够简单时，往往不会意识到编码规范和代码质量的重要性。当项目大到需要多人协作或是接收别人的代码时，你就会意识到，编码规范的统一、项目结构的设计、代码的易读性和规范的注释是多么重要。
提高编码质量不仅仅可以帮你快速的定位到bug，更能有效的减少bug数量。糟糕的代码就像堆在一起的杂物，而高质量的代码就像是分门别类的收纳箱，在找东西时 ，哪个效率更高是显而易见的。
当然，提高编码质量不是一蹴而就的，需要有扎实的基础知识，良好的编码规范，以及日积月累的犯错经验。之后可以专门写一篇文章，来介绍如何编写高质量的代码。
阅读报错信息
如果浏览器有输出错误信息，那么根据错误信息，我们就能大致判断出错误类型以及可能出错的原因。
比如:
- 根据如下报错信息，我们看到，代码在运行时，试图去访问某一对象的
attr属性，而该对象并没有被定义。这时候，我们只要在出错的页面去检索关键词attr，输出attr所依赖的对象，就知道错误出在哪儿了
Uncaught TypeError: Cannot read property 'attr' of undefined
- map是数组才有的方法，这里可以预见的是，a并不是一个数组，结果就是 a 没有达到我们预期的格式
Uncaught TypeError: a.map is not a function
- js代码格式错误，通常ESLint会输出报错，检查一下引号、逗号、小括号、大括号是否写完整
Uncaught SyntaxError: Invalid or unexpected token
-
有时候，即便是看懂了报错信息，也不清楚自己的代码到底出了什么问题。你可以把报错信息复制下来，去stackoverflow，segmentfault等专业问答网站去检索一下，如果找到不到合理的答案，还可以去google或百度去搜。要相信，总有人会和你遇到过类似的问题。
善用console
有时候，代码不能以期望的方式运行，但又没有输出任何有效的错误信息，我们可以使用console方法，将必要的信息打印出来。
如何使用？
比如，但我们点击提交按钮时，并没有发起提交请求。这时，我们要查看源码，找出从点击提交按钮一直到发起请求中间，都执行了哪些步骤。并将关键步骤处的关键信息输出，比如if else的判断条件、被遍历的数组和对象，以及可能中断执行的return语句。
注意事项
在使用console输出时，建议带上关键词，且不建议使用无意义的数字、字母等：
// good
console.log('attrValue', this.attrValue)
console.log('getModule方法的判断条件', isShow)
// bad
console.log(666, this.attrValue)
console.log(isShow)
另外，在错误排除后，建议删除不再使用的console调试代码，避免在查找其他错误时，造成不必要的干扰。
排除法
这个方法之前明明是正常的，我并没有改动它，只是在其他地方加了一些代码，它就不正常了。
怎么办？假使页面中一共有abcd五个方法，我们逐次注释掉a, b , c , d，每注释掉一个就运行一次代码，如果在注释掉d以后，代码运行正常了，那么问题就出在d身上。
剥离法
如果页面的代码量很大，用排除法效率可能会很低，这时候我们可以试试剥离法。
同样一个方法（组件），在A页面运行没有问题，放到B页面就不行。这时候，可以建一个新的页面，里面只放这一个组件，然后运行，如果没有异常，首先可以排除，不是这个组件的问题。接下来，把B页面可能对该方法（组件）造成影响的条件，逐次添加进来，看看到底是哪个条件造成了异常。
线上故障排除
有时候线上代码出了故障，而本地又无法重现，由于线上代码不能使用console，并且上线代码都经过了压缩混淆，导致很难调试。
这时候可以试试sourceMap，在webpack的配置文件中开启sourceMap，在打包的时候会生成对应的.map文件。然后将打包过的文件整体上传到服务器，这样调试线上代码时，除了压缩混淆过的代码，还会有一份原始代码，方便打断点和阅读代码。
不过这样做也会有一些缺点，一是打包时间会变长，二是将原生代码暴露出去。所以，平时建议关闭sourceMap功能，只有在修复无法在本地重现的线上bug时再使用。而且，在修复完毕后，重新打一个没有sourceMap的包，上传到服务器，避免本地代码泄露。
