likes
comments
collection
share

前端调试的正确姿势

作者站长头像
站长
· 阅读数 248

前言

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

查找代码

找到出错的地方才能debug,那怎么高效地找到出问题的代码。

console.log

通常我们遇到bug,第一直觉肯定看console的报错信息,

前端调试的正确姿势

这种报错,错误原因和报错位置一目了然,很方便就定位到出问题的代码,所以console.log虽然显得有点低级,但它简单实用,简单的缺陷还是可以通过这种方法定位的,生产环境利用webpack去掉,就不会影响性能方面(有文章分析过console.log会导致内存泄漏,可以查看)。

全局查找

可以根据出问题的地方关键字,一般是dom元素的id,class,name或者页面中出现的唯一性的中文汉字,搜索就可以直接定位到代码。

调用堆栈

堆栈是一个数据结构,每一个函数调用时都会将函数的指针和参数值保存到堆栈中,后进先出,最后调用的函数最先出栈。

可以通过打断点,查看Chrome开发面板的sources的call stack,可以查看追溯到源代码的位置,这个特别适合console报错位置不明确的情况(比如报错指向vue.esm.js)。

前端调试的正确姿势

分析代码

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

断点

  1. 直接在代码里debugger

    在代码运行到该处就能触发断点,这对于sources面板不好找源码特别方便,麻烦之处就是需要记住去掉,不然后续开发经常会被断点。

  2. sources源码中加断点

    这种打断点非常方便,但有时候没那么容易找到源码。

  3. dom修改时加断点

    前端调试的正确姿势

  4. ajax请求断点

    前端调试的正确姿势

    1. 异常时断点

      前端调试的正确姿势

调试代码

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

  1. vue-cli的本地代理功能,在配置文件devServer.proxy中配置反向代理,这种方式最好弄一个网站作为中介代理,开发的时候只需要修改网站上的配置,本地服务不用重复启动。
  2. 自己搭建nginx反向代理,效果同上。
  3. 后端接口设置Access-Control-Allow-Origin,利用cors跨域本地直接访问线上数据,这种方法最方便,但需要后端同事配合。
  4. 使用fiddler AutoResponder功能,直接把服务器重定向到本地目录(需要编写一个正则表达式),修改本地文件刷新浏览器就能看的修改效果。
  5. 使用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语句了。

本文由博客一文多发平台 OpenWrite 发布!