很多同學不知道爲什麼要用 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 的函數組件,你可以看到渲染這個函數組件會經歷 workLoop、beginWork、renderWithHooks 這些流程:
你可以點開調用棧的每一幀看下都執行了啥邏輯,用到啥數據。比如可以看到這個函數組件的 fiber 節點:
再就是作用域,點擊每一個棧幀就可以看到每個函數的作用域中的變量:
用 Debugger 可以看到代碼的執行路徑,每一步的作用域信息。而你用 console.log 呢?
只能看到那個變量值而已。
拿到的信息量的差距不是一點半點,調試時間長了,別人會對代碼的運行流程越來越清晰,而你用 console.log 呢?還是老樣子,因爲你看不到代碼執行路徑。
所以,不管是調試庫的源碼還是業務代碼,不管是調試 Node.js 還是網頁,都推薦用 Debugger 打斷點,別再用 console.log 了,就算想打印日誌,也可以用 LogPoint。
而且在排查問題的時候,用 Debugger 的話可以加一個異常斷點,代碼跑到拋異常的地方就會斷住:
可以看到調用棧來理清出錯前都走了哪些代碼,可以通過作用域來看到每一個變量的值。
有了這些東西,排查錯誤不就很輕鬆了麼!
而你用 console.log 呢?
啥也沒,只能自己猜。
由於本篇文章都是gif動圖,今天上傳太累了,要看全文,請點擊以下鏈接: