前言平时工作量大，自测的时间不多。写代码难免不小心写出bug。同时，频繁测试的时间紧，留给开发修正缺陷的时间如果掌握了正确的调试姿势，就可以快速定位问题，从容应对。本文主要讲一下前端调试的正确姿势，希望对大家有所帮助。找代码找错误的地方调试，那么如何高效的找到错误的代码。console.log通常我们遇到bug，第一反应就是看控制台的错误信息。这种报错，报错原因和报错位置一目了然，定位有问题的代码也很方便，所以虽然console.log看起来有点低级，但是很简单这种方法仍然可以定位实用且简单的缺陷。生产环境如果被webpack去掉，不会影响性能（有文章分析过console.log会导致内存泄露，可以查看）。全局搜索可以根据问题发生的地方的关键字，一般是id、class、dom元素的名称或者页面出现的唯一汉字，搜索可以直接定位到代码。调用栈栈是一种数据结构。每个函数被调用时，函数的指针和参数值都会保存在栈中，后进先出，最后调用的函数最先出栈。通过断点可以在Chrome开发面板查看源码的调用栈，可以查看回溯到源码的位置。这特别适用于控制台报错位置不明确的情况（比如报错指向vue.esm.js）。分析代码分析代码最常用的方法是断点调试，一步步查看结果，定位问题。断点直接在代码中。当代码在那里运行时，调试器可以触发断点。这对于难以找到源代码的源代码面板尤其方便。麻烦的是需要记得去掉，否则后续开发经常会断掉。在sources源码中加断点是很方便的，但是有时候找源码就不是那么容易了。修改dom时加断点。Ajax请求断点异常。调试代码时，最好保持本地环境和线上环境一致，这样修改的缺陷不会被测试验证。那么如何让本地环境和线上环境保持一致呢？vue-cli的本地代理功能在配置文件devServer.proxy中配置了反向代理。这样，最好使用网站作为中介代理。开发时只需要在网站上修改配置即可，无需重复启动本地服务。自己搭建nginx反向代理，效果同上。在后台界面设置Access-Control-Allow-Origin，使用cors直接跨域访问线上数据。这种方式最方便，但是需要后台同事的配合。使用fiddler的AutoResponder功能直接将服务器重定向到本地目录（需要写正则表达式），修改本地文件，刷新浏览器即可看到修改效果。使用ChromeDevTools的Overrides功能将服务器的文件映射到本地，可以支持在sources面板中的修改方式直接生效。这个最适合调试jsp等不需要webpack压缩的老项目。调试技巧（持续更新中）trycatch最近工作中遇到了一个问题。在使用trycatch的逻辑中，报错了，但是浏览器报错并指出了错误的位置，但是没有给出具体的原因。这一行的逻辑是指向另外一个文件的函数，也就是整个逻辑链条比较长，后面定位问题也花了很长时间。后来在想是不是trycatch的原因，还是我自己的写法。js是单线程的，报错会导致后续语句阻塞。trycatch的主要目的是为了避免一些未知的错误，防止语句阻塞。用trycatch没有问题，自己的写法应该也没有问题，只是定位问题的方式太简单了。其实可以通过上面的异常捕获来定位问题。捕获到异常后，可以通过调用栈看到调用顺序，然后顺藤摸瓜而不是盯着错误行进行验证。顺便介绍一下新版Chrome的一个调试功能。本来我们打印的时候一般都需要在源码中写console.log。我们还提到console.log会影响性能。除了在生产环境使用webpack去除console.log，新版Chrome还提供了更方便的打印方式。这样就不需要在源码中添加console.log语句了。本文由博客多发平台OpenWrite发布！
