從一句面試問題講起#

Debug 是工程師每天都在做的事，能不能順利定位問題，往往決定了一整天的心情和產出。但奇怪的是，相較於演算法、框架、設計模式，「Debug 技巧」這件事本身被討論得相對少。

原作者在第一次面試實習時被問到「你怎麼 Debug？」，當下只答得出「打開 DevTools 看 console.log」，並且抱持著「一個 log 不夠就放更多 log」的心態硬幹。雖然多半也能找到問題，但事後反省才發現：明明每天都開 Chrome DevTools，卻只用到 console.log，DevTools 還有非常多功能完全沒碰過。

這也是這份筆記想處理的問題：把那些「你不知道但其實非常實用」的 DevTools 功能整理成可重複使用的工作流程。

這份筆記想寫給誰#

只要你有網頁開發經驗，特別符合以下幾種情境，這份筆記都會有幫助：

• 每天都會開瀏覽器的 DevTools
• 經常需要刻 UI、寫大量 HTML 與 CSS
• 以 JavaScript 維生，常常追蹤事件、非同步流程的問題
• 需要做前端效能優化、SEO 優化

這份筆記以 Chrome DevTools 為主軸，逐一走過各個 panel 與實用的小技巧，並結合實際 Debug 情境來幫助理解。大部分章節彼此獨立，可以直接跳到有興趣的主題，不一定要從頭照順序看完。

不只談 DevTools#

DevTools 不是 Debug 的唯一解。原作者整理出幾種 DevTools 之外的 Debug 方式，這些原則同樣關鍵。

善用搜尋#

很多問題其實 Google 一下就能解決。但隨著經驗增加，會發現 Stack Overflow、部落格的「直接答案」並不是最有價值的來源。更好的習慣是：

• 主動翻 MDN 文件，了解規範本身怎麼說
• 看官方文件的 FAQ 與 Caveats（已知陷阱）
• 看 GitHub Issues，特別是「為什麼設計成這樣」的討論
• 必要時直接讀規範（spec）

這種一手資料的累積，比每次都靠別人嚼過的答案更有複利。

主動提問#

向有經驗的人或社群提問是非常有效的解法，但前提是已經做過功課：

• 先自己研究過，再提問
• 把問題定義清楚，提供足夠的脈絡
• 提供可重現的最小範例（minimal reproduction）

只要其他人能在自己的環境重現問題，幾乎一定能解決。

不要鑽牛角尖#

如果搜了很多關鍵字都查不到任何相關資訊，很有可能是搜尋方向錯了。常見情況是：

• 真正出錯的不是套件本身，而是自己的拼字、手誤
• 編輯器自動補上了不預期的語法
• 抓錯了真正的 root cause，搜尋的是症狀而不是原因

當所有路都走不通時，先停下來，重新檢視問題定義。

放鬆身心#

卡了好幾個小時找不到 Bug 的時候，離開鍵盤散步、買杯飲料、洗個澡，常常會在最放鬆的時候突然想到解法。這不是玄學，而是大腦需要切換 mode 才能跳出原本的思維框架。

系列涵蓋的範圍#

接下來的章節主要圍繞以下幾個主題：

• Chrome DevTools 各個 panel 的核心用法（Elements、Console、Sources、Network、Performance 等）
• 與其他瀏覽器 DevTools 的比較
• Web Vitals、SEO 等指標相關的 Debug 工具
• 效能優化常見的觀察與診斷流程

大部分情境都來自實際開發遇到的問題，建議搭配 Demo 頁面實際操作，比起只看文字會記得更深。

原文出處#

• 原書/iThome：https://ithelp.ithome.com.tw/articles/10236769