很多同學(xué)不知道為什么要用 debugger 來調(diào)試，console.log 不行么？還有，會用 debugger 了，還是有很多代碼看不懂，如何調(diào)試復(fù)雜源碼呢？這篇文章就來講一下這篇文章就來講一下為什么要用這些調(diào)試工具,希望對大家有所幫助！

console.log vs Debugger

相信絕大多數(shù)同學(xué)使用 console.log 調(diào)試的，把想看的變量值打印在控制臺?！鞠嚓P(guān)教程推薦：nodejs視頻教程、編程教學(xué)】

這樣能滿足需求，但是遇到對象的打印就不行了。

比如我想看 webpack 源碼里的 compilation 對象的值，我打印了一下：

但你會發(fā)現(xiàn)對象的值也是對象的時(shí)候不會展開，而是打印一個(gè) [Object] [Array] 這種字符串。

更致命的是打印的太長會超過緩沖區(qū)的大小，terminal 里會顯示不全：

而你用 debugger 來跑，在這里打個(gè)斷點(diǎn)來看就沒這些問題了：

有的同學(xué)可能會說，那打印一個(gè)簡單的值的時(shí)候用 console.log 還是很方便呀。

比如這樣：

真的么？

那還不如用 logpoint：

代碼執(zhí)行到這里就會打?。?/p>

而且沒有污染代碼，用 console.log 的話調(diào)試完之后這個(gè) console 不也得刪掉么？

但是 logpoint 不用，它就是個(gè)斷點(diǎn)的設(shè)置，不在代碼里。

當(dāng)然，最重要的是 Debugger 調(diào)試是可以看到調(diào)用棧和作用域的！

首先是調(diào)用棧，它就是代碼的執(zhí)行路線。

比如這個(gè) App 的函數(shù)組件，你可以看到渲染這個(gè)函數(shù)組件會經(jīng)歷 workLoop、beginWork、renderWithHooks 這些流程：

你可以點(diǎn)開調(diào)用棧的每一幀看下都執(zhí)行了啥邏輯，用到啥數(shù)據(jù)。比如可以看到這個(gè)函數(shù)組件的 fiber 節(jié)點(diǎn)：

再就是作用域，點(diǎn)擊每一個(gè)棧幀就可以看到每個(gè)函數(shù)的作用域中的變量：

用 Debugger 可以看到代碼的執(zhí)行路徑，每一步的作用域信息。而你用 console.log 呢？

只能看到那個(gè)變量值而已。

拿到的信息量的差距不是一點(diǎn)半點(diǎn)，調(diào)試時(shí)間長了，別人會對代碼的運(yùn)行流程越來越清晰，而你用 console.log 呢？還是老樣子，因?yàn)槟憧床坏酱a執(zhí)行路徑。

所以，不管是調(diào)試庫的源碼還是業(yè)務(wù)代碼，不管是調(diào)試 Node.js 還是網(wǎng)頁，都推薦用 Debugger 打斷點(diǎn)，別再用 console.log 了，就算想打印日志，也可以用 LogPoint。

而且在排查問題的時(shí)候，用 Debugger 的話可以加一個(gè)異常斷點(diǎn)，代碼跑到拋異常的地方就會斷?。?/p>

可以看到調(diào)用棧來理清出錯(cuò)前都走了哪些代碼，可以通過作用域來看到每一個(gè)變量的值。

有了這些東西，排查錯(cuò)誤不就很輕松了么！

而你用 console.log 呢？

啥也沒，只能自己猜。

Performance

前面說 Debugger 調(diào)試可以看到一條代碼的執(zhí)行路徑，但是代碼的執(zhí)行路徑往往比較曲折。

比如那個(gè) React 會對每個(gè) fiber 節(jié)點(diǎn)做處理，每個(gè)節(jié)點(diǎn)都會調(diào)用 beginWork。處理完之后又會處理下一個(gè)節(jié)點(diǎn)，再次調(diào)用 beginWork：

就像你走了一條小路，然后回到大路之后又走了另一條小路，用 Debugger 只能看到當(dāng)前這條小路的執(zhí)行路徑，看不到其他小路的路徑：

這時(shí)候就可以結(jié)合 Performance 工具了，用 Performance 工具看到代碼執(zhí)行的全貌，然后用 Debugger 來深入每一條代碼執(zhí)行路徑的細(xì)節(jié)。

SourceMap

sourcemap 很重要，因?yàn)槲覀儓?zhí)行過的都是編譯打包后的代碼，基本是不可讀的，調(diào)試這種代碼也沒啥意義，而 sourcemap 就可以讓我們直接調(diào)試最初的源碼。

比如 vue，關(guān)聯(lián)了 sourcemap 之后，我們能直接調(diào)試 ts 源碼：

nest.js 也是：

不用 sourcemap 的話，想搞懂源碼，但你調(diào)試的是編譯后的代碼，怎么讀懂呢？

讀懂一行

前面說的 Debugger、Performance、SourceMap 只是調(diào)試代碼的工具，那會了調(diào)試工具，依然讀不懂代碼怎么辦呢？

我覺得這是不可能的。

為什么這么說呢？

就拿 react 源碼來說：

switch case 能讀懂吧。三目運(yùn)算符能讀懂吧。函數(shù)調(diào)用能讀懂吧。

每一行代碼都能讀懂，而全部的代碼不就是由這一行行代碼組成的么？

加上我們可以單步執(zhí)行來知道代碼執(zhí)行路徑。

為啥每行代碼都能讀懂，連起來就讀不懂了呢？

那應(yīng)該是代碼太多了，而你花的時(shí)間不夠而已。

先要讀懂一行，一個(gè)函數(shù)，讀懂一個(gè)小功能的實(shí)現(xiàn)流程，慢慢積累，之后了解的越來越多之后，你能讀懂的代碼就會越多。

總結(jié)

這篇文章講了為什么要用調(diào)試工具，如何讀懂復(fù)雜代碼。

console.log 的弊端太多了，大對象打印不全，會超過 terminal 緩沖區(qū)，對象屬性不能展開等等，不建議大家用。就算要打印也可以用 LogPoint。

用 Debugger 可以看到調(diào)用棧，也就是代碼的執(zhí)行路徑，每個(gè)棧幀的作用域，可以知道代碼從開始運(yùn)行到現(xiàn)在都經(jīng)歷了什么，而 console.log 只能知道某個(gè)變量的值。

此外，報(bào)錯(cuò)的時(shí)候也可以通過異常斷點(diǎn)來梳理代碼執(zhí)行路徑來排查報(bào)錯(cuò)原因。

但 Debugger 只能看到一條執(zhí)行路徑，可以用 Performance 錄制代碼執(zhí)行的全流程，然后再結(jié)合 Debugger 來深入其中一條路徑的執(zhí)行細(xì)節(jié)。

此外，只有調(diào)試最初的源碼才有意義，不然調(diào)試編譯后的代碼會少很多信息?？梢酝ㄟ^ SourceMap 來關(guān)聯(lián)到源碼，不管是 Vue、React 的源碼還是 Nest.js、Babel 等的源碼。

會了調(diào)試之后，就能調(diào)試各種代碼了，不存在看不懂的源碼，因?yàn)槊恳恍写a都是基礎(chǔ)的語法，都是能看懂的，如果看不懂，只可能是代碼太多了，你需要