網站壞了，怎麼找問題 · 第 02 章
先看主控台，再看網路請求
分辨前端程式錯誤、請求錯誤與欄位驗證，避免看到一段紅字就整頁重寫。
貓老闆的簡報
你說伺服器壞了，有沒有真的送過請求？先看證據。
——貓掌櫃官網的老闆「掌櫃」下需求時的原話
這章做什麼
為問題補上主控台與 Network 面板的觀察紀錄，縮小排查範圍。
動手做
- 開啟開發者工具的 Console，清空舊訊息後重做操作，記下新錯誤和對應檔案位置。
- 在 Network 重做送出，觀察有沒有請求、請求網址與 HTTP 狀態碼；不要把完整標頭或含帳密的請求貼給 AI。
- 沒有請求時先看欄位驗證和事件處理；有請求卻錯誤時，再看回應和後端日誌。狀態碼是線索，不能單憑它認定原因。
- 若伺服器已回成功但畫面沒變，再排查前端如何處理回應；把觀察和假設分開寫。
親手試試
模擬：Network 沒出現送出紀錄。先查欄位驗證、按鈕事件和 Console，不先改後端。
模擬：請求有送出並回 500。記錄時間和可公開的錯誤摘要，再查後端日誌。
模擬：API 回傳成功與編號。檢查前端是否讀對回應欄位並更新畫面。
這是排查方向模擬，不能代替閱讀實際錯誤內容。
這樣對 AI 說
中文就可以
我會貼遮蔽敏感資訊後的 Console 錯誤、Network 狀態和後端摘要。請先判斷問題可能出在哪一段，引用具體線索，列出下一個最小檢查動作；不要只憑狀態碼下結論。沒有請求、請求錯誤、成功卻沒有回饋要分別考慮，證據不足就明說。
本章驗收清單
請在自己的練習專案實際操作，再依結果逐項確認。
- 只記錄重做操作時的新訊息
- 能確認請求是否有送出
- 狀態碼與回應內容一起判讀
- 沒有把憑證或完整個資貼給 AI
這章的相關詞條
詞條頁都有可以動的示範——卡住的時候，去把名詞弄清楚，回來繼續做。
官方參考資料
進度只存在這台瀏覽器，不上傳、不追蹤。