前端调试的正确姿势 vue.js前端

前言

平时工作量大，没有很多的自测时间，难免会在写代码的时候一不小心写出BUG，同时经常测试的时间又紧，留给开发修改缺陷的时间少，如果掌握正确的调试姿势，就能快速定位问题，从容应对。本文就主要讲一下前端调试的正确姿势，希望能够给到大家帮助。

查找代码找到出错的地方才能debug，那怎么高效地找到出问题的代码。
console.log
通常我们遇到bug，第一直觉肯定看console的报错信息，

文章图片

这种报错，错误原因和报错位置一目了然，很方便就定位到出问题的代码，所以console.log虽然显得有点低级，但它简单实用，简单的缺陷还是可以通过这种方法定位的，生产环境利用webpack去掉，就不会影响性能方面（有文章分析过console.log会导致内存泄漏，可以查看）。
全局查找
可以根据出问题的地方关键字，一般是dom元素的id,class,name或者页面中出现的唯一性的中文汉字，搜索就可以直接定位到代码。
调用堆栈
堆栈是一个数据结构，每一个函数调用时都会将函数的指针和参数值保存到堆栈中，后进先出，最后调用的函数最先出栈。
可以通过打断点，查看Chrome开发面板的sources的call stack，可以查看追溯到源代码的位置，这个特别适合console报错位置不明确的情况（比如报错指向vue.esm.js）。

文章图片

分析代码分析代码最常用的就是断点，一步步调试查看结果，定位问题。
断点

直接在代码里debugger
在代码运行到该处就能触发断点，这对于sources面板不好找源码特别方便，麻烦之处就是需要记住去掉，不然后续开发经常会被断点。
sources源码中加断点
这种打断点非常方便，但有时候没那么容易找到源码。
dom修改时加断点

文章图片
ajax请求断点
【前端调试的正确姿势】
文章图片
1. 异常时断点
  
  文章图片

调试代码调试代码，最好保持本地环境和线上环境一直，这样基本保证修改缺陷不会被测试验证不过。那怎么保持本地环境和线上保持一致呢。

vue-cli的本地代理功能，在配置文件devServer.proxy中配置反向代理，这种方式最好弄一个网站作为中介代理，开发的时候只需要修改网站上的配置，本地服务不用重复启动。
自己搭建nginx反向代理，效果同上。
后端接口设置Access-Control-Allow-Origin，利用cors跨域本地直接访问线上数据，这种方法最方便，但需要后端同事配合。
使用fiddler AutoResponder功能，直接把服务器重定向到本地目录（需要编写一个正则表达式），修改本地文件刷新浏览器就能看的修改效果。
使用Chrome DevTools的Overrides功能，把服务器的文件映射到本地，可以支持在sources面板中修改方法直接生效，这种最适合调试jsp这种不用webpack压缩的老项目。

调试技巧（不断更新中） try catch
最近工作中遇到一个问题，在使用的try catch的逻辑中，报错了，但浏览器报错指出了报错的位置，但没有给出具体的原因，这行的逻辑是指向了另外一个文件的函数，就是整条逻辑链比较长，后面定位问题花了很长时间，后面我在思考这是try catch的原因还是我自己写法的原因。
js是单线程的，报错会导致后续的语句阻塞，try catch主要的用途就是规避一些未知的错误，防止语句阻塞。使用try catch是没有问题的，自己的写法应该也没有问题，就是定位问题的方式太单一，其实是可以使用上面提到的异常捕获来定位问题。

文章图片

异常捕获之后，可以通过调用堆栈看到调用顺序，再顺藤摸瓜，而不是一直盯着报错的行进行验证。
顺便介绍一个Chrome新版本的一个调试功能，原本我们打印一般需要写在源码里写console.log，前面也讲到console.log会影响性能，除了可以用webpack在生产环境的时候去掉console.log，新版本的Chrome还提供了一个更加方便的打印方法。

这样就不用在源码里面添加console.log语句了。