Chrome Developer Tools之调试代码

转载地址

随着越来越多复杂js应用的出现，开发者需要强大的调试工具去帮助自己快速的发现代码中导致问题发生的根源，并有效的修复它们！chrome的开发者工具包含了一套强大的工具，使得调试javascript不再痛苦！

源码面板
源码面板提供了一个可视化界面来调试你的js代码，下面我们来看一下这个面板的细节：

源码面板让你可以查看当前页面中包含的所有脚本，并支持单步调试，其实熟悉后端开发的童鞋，对单步调试肯定不陌生~但是我还是按照手册上的介绍，翻译一下细节吧~
上图中标注的那个“调试按钮”工具条，就是DevTools提供给我们的调试面板~
从左至右我们一个一个来介绍：
第一个按钮：Continue，如它的字面意思：让代码继续执行，直到遇见下一个断点，热键是F8；

第二个按钮：Step over，当我们在逐行调试代码时，当遇到某一个函数调用时，为了避免不必要的细节，我们可能并不需要进入该函数，而是想继续在当前上下文中调试，这个时候就需要点击该按钮，热键是F10；

第三个按钮：Step into，和第二个按钮的作用刚好相反，碰到函数调用，会进入到被调用的函数中，颇有种打破砂锅问到底的魄力，热键是F11；

第四个按钮：Step out，用于快速跳出当前函数，返回到调用当前函数的“父”上下文中，结合上面的几个按钮可以满足各种调试需求，热键是Shift + F11；

第五个按钮：Toggle breakpoints，这个最简单，就是全局设置断点是否有效的开关。

断点
所谓断点，是指在代码中为了调试目的而需要被暂停执行的位置，听起来很绕口，但实际却非常的直观！下面让我们举个实际的例子。

首先，我们在源码面板中随意找到一个js脚本，然后在代码行号上点击鼠标左键，好的，你已经成功的创建了一个断点！

我们设置的所有断点，都可以在右边栏的“Breakpoints”选项卡中看到，如上图~
取消一个断点也很简单，只需要在此单击想要取消的断点即可~

一旦你设置了一个断点，你可以在该蓝色图标上鼠标右键，弹出的菜单中显示了你可以对该断点进行的操作，包括：”Continue to here”, “Edit Breakpoint”, “Disable Breakpoint” and “Remove Breakpoint”~
名字都直观的，不是么？
我们主要来说一下断点的“条件声明”，该功能支持对断点设置一个表达式，当表达式为真时，断点才会生效~
举个例子，如果你的代码中有一个功能，每20毫秒触发一次，你可能并不希望每次执行它都会触发你设置的断点，这个时候你就可以设置一个条件断点，当然，你还需要在代码中维护用于条件判断的变量值。

好的，我们已经成功的设置了断点，现在刷新页面，你会发现当执行到你设置的断点时，页面停止在断点对应的那行代码了！
不仅如此，你还可以通过右边栏的“Call Stack”选项卡查看当前的调用堆栈详情，在“Scope Variables”选项卡中查看当前时刻声明过的变量列表~

注意，在DevTools中设置断点可能并不是你喜欢的方式，你还可以在你的代码中设置断点，具体细节可以看这里。

下面模拟一些场景，来介绍一些DevTools提供的印巴的调试技巧，这些例子都来自于官方文档，不过由于被墙了的原因，我只能自己写代码模拟了~为了节省时间，我擅自忽略了一些不太印巴的技巧，拿出来说的都是一些相对更印巴的~这里我还要提醒一句，针对js的特性，DevTools提供了一些后端debug没有的功能来加速调试效率！希望后端童鞋能仔细品味下面的内容~

---

1.DOM上的断点
src="http://jsbin.com/egeNopuM/1/embed?output" id="" style="max-width: 100%; margin: 0px auto; display: block; color: rgb(51, 51, 51); font-family: 微软雅黑, Arial, Helvetica, sans-serif; font-size: 16px; border: 1px solid rgb(170, 170, 170); width: 1125.890625px; min-height: 300px; height: 30px;">

2.XHR上的断点
src="http://jsbin.com/emUHUgAN/1/embed?output" id="" style="max-width: 100%; margin: 0px auto; display: block; border: 1px solid rgb(170, 170, 170); width: 1125.890625px; min-height: 300px; height: 30px;">

3.js事件上的断点

---

动态编辑源码
如果我们可以在调试的时候动态更改代码，那该是多屌炸天的能力啊！没错，在DevTools中你完全可以这么做！
你只需要在源码面板中找到你要更改的脚本文件，然后修改，然后保存（一定要保存啊！），然后你就可以看到新的版本了~这极大的提高了调试效率，避免了你不停的在浏览器和IDE之间来回切换~

这里要提醒的是你的修改只是在当前场景下有效，刷新页面后你的修改将会丢失，当然你还可以通过其他设置来持久化修改，这不是本文的主题，在这里就不多说了~

异常
现在让我们把注意力集中在讨论异常的相关细节上！

通常情况下，我们会对可能抛出异常的代码进行异常处理，这种方案总是会改变代码的正常流程~
当出现问题时，你可以查看DevTools的“控制台面板”来查看错误信息，并且可以直接点击错误跳转到错误对应的代码位置！

导致错误发生的情况有很多，也可能很复杂，尤其是错误很可能并不是每次都发生，而是在特定执行流程上才会抛出，如何更容易定为错误发生的场景呢？这就要看控制台为每个错误显示的完整的调用堆栈信息了，可以展开错误信息来查看~

一般当你在控制台看到错误信息，意味着这些错误都是你无法预知的~
接下来我们看一下那些预料之内的错误应该如何处理~~

Error.stack
每个错误对象都有一个“stack”属性，该属性包含了错误的堆栈信息，如果你需要查看的话，直接在控制台打印出来即可！

console.trace()
当然，并非只能借助异常才能获取想要查看的调用堆栈信息，你可以随时通过“console.trace();”方法打印任何上下文调用堆栈信息！

console.assert()
熟悉单元测试的童鞋对断言肯定非常熟悉，同样，在你的js代码中依然可以简单的通过“console.assert()”来实现断言，当传递的表达式为非真时会抛出异常！

利用window.onerror来定制全局异常捕获
Chrome允许你通过给window.onerror绑定处理函数来捕获那些没有被任何try/catch块捕获到而扩散到全局的异常！你可以很方便的利用这个特性把任何客户端的未捕获异常发回到服务器端，注意下面截图中为onerror绑定的函数的参数：

格式化代码格式
如果你要调试的代码经过了压缩，那么格式化代码功能会让你的调试更加舒心，你只需要点击“{}”按钮即可立即看到赏心悦目的代码！

到此为止，我们就已经把常用的debug技巧介绍完毕了，希望能帮助到你！妥妥儿的！