共计 1632 个字符，预计需要花费 5 分钟才能阅读完成。
前言
平时工作量大，没有很多的自测工夫，难免会在写代码的时候一不小心写出 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 申请断点
异样时断点
调试代码
调试代码，最好放弃本地环境和线上环境始终，这样根本保障批改缺点不会被测试验证不过。那怎么放弃本地环境和线上保持一致呢。
- 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 语句了。
本文由博客一文多发平台 OpenWrite 公布！
