许多同学不清楚为什么使用 debugger 来调节，console.log 不好么？
也有，用到 debugger 了，还是有一些编码不明白，如何调试繁杂源代码呢？
本文就来讲一下为什么使用这种调试工具：
console.log vs Debugger
我相信绝大部分同学们应用 console.log 调节的，把想看的视频变量类型打印出在控制面板。
这样可以满足要求，如果遇到对象打印出就没有了。
例如我要看 webpack 源代码中的 compilation 目标数值，我打印出了一下：
但你就会发现目标数值都是目标时不会进行，反而是打印出一个 [Object] [Array] 这类字符串数组。
更致命性的是打印过长会超过缓冲区域大小，terminal 中会显示不全：
但你用 debugger 来跑，在这儿打一个中断点来说也没这种问题：
许多学生可能说，那打印出一个简单的值时用 console.log 还是非常便捷呀。
例如那样：
真的么？
还不如直接用 logpoint：
执行命令到这儿便会打印出：
并且无污染编码，用 console.log 得话调节完以后这一 console 也得删除么？
可是 logpoint 无需，它是个中断点设置，没有在编码里。
自然，最主要的是 Debugger 调节是能够看见调用栈和修饰符的！
关键在于调用栈，它是代码的实行路经。
你看这个 App 的函数公式部件，你会看到3D渲染这一函数公式部件会经历 workLoop、beginWork、renderWithHooks 这种步骤：
你能打开调用栈的每一帧看中都实施了啥逻辑性，使用啥数据信息。或者可以看到这样的函数公式元件的 fiber 连接点：
再有就是修饰符，点一下每一个栈帧就能看到每一个函数的作用域里的自变量：
用 Debugger 能够看见代码的实行途径，每一步的修饰符信息内容。但你用 console.log 呢？
只看到了那一个变量类型罢了。
取得的信息量的差距并不是一点半点，调节时间久了，他人会让代码的运作步骤愈来愈清楚，但你用 console.log 呢？还是那样，由于你看不见执行命令途径。
因此，不论是调节库的源代码或是业务代码，不论是调节 Node.js 或是网页页面，都推荐使用 Debugger 打断点，别再换 console.log 了，即使想打印出日志，还可以用 LogPoint。
并且在查找问题时，用 Debugger 的话也可以加一个出现异常中断点，编码跑进抛异常的地方都会断住：
能够看见调用栈来梳理出差错前也走了什么编码，能通过修饰符来见到每一个自变量数值。
拥有这个东西，清查不正确那不就非常轻松了吗！
但你用 console.log 呢？
什么也没，只有自己猜。
Performance
前边说 Debugger 调节能够看见一条代码的实行途径，可是代码的实行途径一般都很坎坷。
例如那一个 React 会让每一个 fiber 连接点做解决，每个节点都是会启用 beginWork。处理完毕以后又解决下一个连接点，再度启用 beginWork：
就好比你离开了一条小路，随后返回大道以后走了另一条小路，用 Debugger 只看到了现阶段这条小路的落实途径，看不见别的小道的路线：
这时候需要结合 Performance 辅助工具，用 Performance 专用工具见到执行命令的全景，随后用 Debugger 来深层次每一条执行命令途径的小细节。
SourceMap
sourcemap 至关重要，只要我们实行过的基本都是编译程序装包后编码，基本上并不是可读的，调节这类编码也没什么实际意义，而 sourcemap 就能够让我们立即调节最初源代码。
例如 vue，关系了 sourcemap 以后，我们可以立即调节 ts 源代码：
nest.js 都是：
无需 sourcemap 得话，想弄懂源代码，但是你调节是指编译程序后编码，如何了解呢？
了解一行
上面说的 Debugger、Performance、SourceMap 仅仅调试代码的一种手段，那时候了调试工具，仍然读不懂编码该怎么办呢？
我认为这不可能。
为什么这样说呢？
就用 react 源代码而言：
switch case 能读懂吧。三目运算符能读懂吧。函数调用能读懂吧。
每一行代码都能读懂，而所有代码这不就是由这一行行编码构成的吗？
再加上我们能断点调试实行来了解执行命令途径。
为什么每排编码都能读懂，连在一起就读不懂了啦？
那应该是编码太多，但你花费时间不足罢了。
需先了解一行，一个函数，了解一个小工具的完成步骤，不断积累，以后知道的愈来愈多以后，你能读懂代码也就越多。
汇总
本文说了为什么使用调试工具，怎样了解繁杂编码。
console.log 的缺点太多，大目标打印不全，会超过 terminal 缓冲区域，对象属性不可以进行等，不太建议用。即使要打印还可以用 LogPoint。
用 Debugger 能够看见调用栈，其实就是代码的实行途径，每一个栈帧的修饰符，就可以知道编码从运行到现在也经历过什么，而 console.log 只有了解某一自变量数值。
除此之外，出错的时候也能做到根据出现异常中断点来整理执行命令途径来清查出错缘故。
但 Debugger 只看到了一条实行途径，可以使用 Performance 拍摄执行命令等各个环节，然后融合 Debugger 来深入其中一条线路的执行细节。
除此之外，仅有调节最初源代码才会有意义，要不然调节编译程序后编码会少很多信息。能通过 SourceMap 来反映到源代码，不论是 Vue、React 的源代码或是 Nest.js、Babel 等源代码。
会了调节以后，就可调节各种各样编码了，不会有难以理解的源代码，由于每一行代码全是基本的词法，全是看得懂的，假如不明白，只有可能是编码太多，你需要更多细心读一行行编码、一个个函数公式、梳理一个个功能性的完成，不断积累就行了。
把握根据 Debugger、Performance、SourceMap 等调试代码以后，各种各样网页页面和 Node.js 编码都可以调节，各种各样源代码都能读懂！
（节选自我小册 《前端调试通关秘籍》）