前言

对于一个开发者来说，开发只是工作里的一个部分，然而修复功能的 bug 才是考验一个开发人员能力的时候，因为写出没有 BUG 的代码是一件很困难的事，不是谁都可以把所有的情况都考虑进去，代码复杂式总会出现一些 BUG 问题，所以才会出现各种各样的日志系统，因为他可以让开发人员从日志内容中找到代码的 BUG 根源，当然也不一定能查到，但这只是调试的一种，而在前端里，日志系统是比较少用的，都是靠浏览器的调试来完成 BUG 查找，而常用的有 console 方式，就是打印内容来定位问题，但这种方式只能应付一般简单的场景，如知道问题在哪，需要进一步核查一下是什么问题之类的，但如果出现 console 量特别大的时候就会出现难以排查。
如:

1
2
3
4
5
6
for(var i=0;i<10;i++){
    conosole.log("1111")
}
for(var j=0;j<10;j++){
    conosole.log("1111")
}

cconsole 的地方为循环调用的，而且是交替的，那么就会意义很难懂。

而最好的调式的方式应该是可以查看调用栈，那么就可以追踪问题的行为，而判断 BUG 怎么修复。

调试方式-console

在一般知道问题所在的情况下是 console 可以简单的快速定位问题原因，而且 console 量大是可以分组。

1
2
3
4
// 分组方式
console.group()
console.log("问题打印");
console.groupEnd();

调试方式-Sources

chrome调试查找问题根源
chrome调试查找问题根源

打开 Sources 可以用来查看页面的源文件，里面包含了 debugger 调式，这是重点。
ctrl+p 查找目标文件，当然也可以使用 console 打印后找到目标文件,点击红圈就可以跳转到目标文件。

console
console

而 debugger 后可以使用->来一步一步走完所有的调用，这样可以更仔细的查找到问题，当不知道问题具体在哪时。

调用栈
调用栈

Call Stack 是当前 debugger 过程的调用栈，可以使用它查看到之前的调用过程，从而推断问题，而且点击对应的调用可以跳转到对应的调用方法上，这样就会可以查看当前调用的信息，但旧的浏览器还不可查看那些调用信息，还有 watch 是把某些变量放入，方面之后 debugger 执行查看到当前监控变量的值变化，Scope 当前调用方法的作用域的变量值，BreakPoints 为所拥有的 debugger 数和具体的 debugger，可以在这里删除 debugger，因为有时不知道 debugger 在哪里打，那么在这里移除是最好的，当前还有其他几个，但暂时没有使用到。

调式方式-error

当控制台报错时，会有报错信息与调用栈信息，而一般报错信息只能判断是什么原因，不能定位问题所在，而这时不用调用栈时很被动的，因为只有报错信息与简单的文件报错位置，在复杂的场景下是不够定位问题的，而这时调用栈的信息就可以让我们推断出问题所在，因为他与以上的 debugger 的调用栈是一样的，所以可以追踪的到的调用行为，以推断出问题，以想出对应的解决方法。

调用栈
调用栈

调式方式有很多种，如请求问题，可以查看 network 等等，优化可以 Memory 等，这些都很好，但我觉得调用栈才是定位问题的最佳方式，因为如果你知道问题的行为，那么你就相当如知道具体的问题在哪里出现，就可以直接针对修复，而现在的日志系统也是趋向用户行为分析来定位具体的问题，所以知道行为就是知道具体问题。