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

发表于 更新于 分类于 Disqus：

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

提高编码质量

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

提高编码质量不仅仅可以帮你快速的定位到bug，更能有效的减少bug数量。糟糕的代码就像堆在一起的杂物，而高质量的代码就像是分门别类的收纳箱，在找东西时 ，哪个效率更高是显而易见的。

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

阅读报错信息

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

比如:

  • 根据如下报错信息，我们看到，代码在运行时，试图去访问某一对象的attr属性，而该对象并没有被定义。这时候，我们只要在出错的页面去检索关键词attr，输出attr所依赖的对象，就知道错误出在哪儿了
1
Uncaught TypeError: Cannot read property 'attr' of undefined
  • map是数组才有的方法，这里可以预见的是，a并不是一个数组，结果就是 a 没有达到我们预期的格式
1
Uncaught TypeError: a.map is not a function
  • js代码格式错误，通常ESLint会输出报错，检查一下引号、逗号、小括号、大括号是否写完整
1
Uncaught SyntaxError: Invalid or unexpected token

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

    ​

善用console

有时候，代码不能以期望的方式运行，但又没有输出任何有效的错误信息，我们可以使用console方法，将必要的信息打印出来。

如何使用？

比如，但我们点击提交按钮时，并没有发起提交请求。这时，我们要查看源码，找出从点击提交按钮一直到发起请求中间，都执行了哪些步骤。并将关键步骤处的关键信息输出，比如if else的判断条件、被遍历的数组和对象，以及可能中断执行的return语句。

注意事项

在使用console输出时，建议带上关键词，且不建议使用无意义的数字、字母等：

1
2
3
4
5
6
7
// good
console.log('attrValue', this.attrValue)
console.log('getModule方法的判断条件', isShow)

// bad
console.log(666, this.attrValue)
console.log(isShow)

另外，在错误排除后，建议删除不再使用的console调试代码，避免在查找其他错误时，造成不必要的干扰。

如果输出的是对象或数组，有可能得到不准确的结果

1
2
3
4
5
let obj = {
	key: 1234
}
console.log(obj) // {key: 555}
obj.key = 555

打断点

Chrome的开发者工具有一个很好用的代码调试工具，就是Breakpoints（断点），与console不同的是，它会在断点处终止程序的执行，可以方便的看到代码在哪一步产生了问题。

相比在代码里写debugger打断点的方式，Chrome的调试工具即便捷，又不产生副作用，所以不推荐在代码里写debugger的方式来调试。

更多关于Chrome开发者工具的介绍与使用信息，可移步：chrome开发者工具的使用

排除法

这个方法之前明明是正常的，我并没有改动它，只是在其他地方加了一些代码，它就不正常了。

怎么办？假使页面中一共有abcd四个方法，我们逐次注释掉a, b , c , d，每注释掉一个就运行一次代码，如果在注释掉d以后，代码运行正常了，那么问题就出在d身上。

剥离法

如果页面的代码量很大，用排除法效率可能会很低，这时候我们可以试试剥离法。

同样一个方法（组件），在A页面运行没有问题，放到B页面就不行。这时候，可以建一个新的页面，里面只放这一个组件，然后运行，如果没有异常，首先可以排除，不是这个组件的问题。接下来，把B页面可能对该方法（组件）造成影响的条件，逐次添加进来，看看到底是哪个条件造成了异常。

线上故障排除

有时候线上代码出了故障，而本地又无法重现，由于线上代码不能使用console，并且上线代码都经过了压缩混淆，导致很难调试。

这时候可以试试sourceMap，在webpack的配置文件中开启sourceMap，在打包的时候会生成对应的.map文件。然后将打包过的文件整体上传到服务器，这样调试线上代码时，除了压缩混淆过的代码，还会有一份原始代码，方便打断点和阅读代码。

不过这样做也会有一些缺点，一是打包时间会变长，二是将原生代码暴露出去。所以，平时建议关闭sourceMap功能，只有在修复无法在本地重现的线上bug时再使用。而且，在修复完毕后，重新打一个没有sourceMap的包，上传到服务器，避免本地代码泄露。

关于sourceMap的更多介绍可以移步以下几个链接：

JavaScript Source Map 详解

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