使用debugger來調(diào)試代碼的原因是什么

這篇文章主要介紹了使用debugger來調(diào)試代碼的原因是什么的相關(guān)知識(shí)，內(nèi)容詳細(xì)易懂，操作簡(jiǎn)單快捷，具有一定借鑒價(jià)值，相信大家閱讀完這篇使用debugger來調(diào)試代碼的原因是什么文章都會(huì)有所收獲，下面我們一起來看看吧。

console.log vs Debugger

相信絕大多數(shù)同學(xué)使用 console.log 調(diào)試的，把想看的變量值打印在控制臺(tái)。

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

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

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

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

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

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

比如這樣：

真的么？

那還不如用 logpoint：

代碼執(zhí)行到這里就會(huì)打?。?/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ù)組件會(huì)經(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í)間長了，別人會(huì)對(duì)代碼的運(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)，代碼跑到拋異常的地方就會(huì)斷?。?/p>

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

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

而你用 console.log 呢？

啥也沒，只能自己猜。

Performance

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

比如那個(gè) React 會(huì)對(duì)每個(gè) fiber 節(jié)點(diǎn)做處理，每個(gè)節(jié)點(diǎn)都會(huì)調(diào)用 beginWork。處理完之后又會(huì)處理下一個(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)試代碼的工具，那會(huì)了調(diào)試工具，依然讀不懂代碼怎么辦呢？

我覺得這是不可能的。

為什么這么說呢？

就拿 react 源碼來說：

關(guān)于“使用debugger來調(diào)試代碼的原因是什么”這篇文章的內(nèi)容就介紹到這里，感謝各位的閱讀！相信大家對(duì)“使用debugger來調(diào)試代碼的原因是什么”知識(shí)都有一定的了解，大家如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。