前端开发—如何快速定位错误

写代码时，通常要耗费大量的时间去排查bug产生的原因，如何快速的定位bug，在很大程度上决定了你的开发效率。下面是我的一些经验分享。

在一个项目足够简单时，往往不会意识到编码规范和代码质量的重要性。当项目大到需要多人协作或是接收别人的代码时，你就会意识到，编码规范的统一、项目结构的设计、代码的易读性和规范的注释是多么重要。

当然，提高编码质量不是一蹴而就的，需要有扎实的基础知识，良好的编码规范，以及日积月累的犯错经验。之后可以专门写一篇文章，来介绍如何编写高质量的代码。

如果浏览器有输出错误信息，那么根据错误信息，我们就能大致判断出错误类型以及可能出错的原因。

比如:

根据如下报错信息，我们看到，代码在运行时，试图去访问某一对象的attr属性，而该对象并没有被定义。这时候，我们只要在出错的页面去检索关键词attr，输出attr所依赖的对象，就知道错误出在哪儿了

Uncaught TypeError: Cannot read property 'attr' of undefined

Uncaught TypeError: a.map is not a function

Uncaught SyntaxError: Invalid or unexpected token

有时候，即便是看懂了报错信息，也不清楚自己的代码到底出了什么问题。你可以把报错信息复制下来，去stackoverflow，segmentfault等专业问答网站去检索一下，如果找到不到合理的答案，还可以去google或百度去搜。要相信，总有人会和你遇到过类似的问题。

有时候，代码不能以期望的方式运行，但又没有输出任何有效的错误信息，我们可以使用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的包，上传到服务器，避免本地代码泄露。

JavaScript Source Map 详解

打破砂锅问到底：详解Webpack中的sourcemap