為什麼你的 Google 表單程式總是不聽話？揭開 JavaScript 除錯的隱藏陷阱

1. 前言：那個讓你抓狂的「執行錯誤」

你有過這種經驗嗎？熬夜照著網路教學改好了 Google 表單的程式碼，滿心期待地按下送出按鈕，結果畫面卻像當機一樣毫無反應。或是明明填了資料，後端試算表卻一片空白。

這種時候，大多數初學者的直覺是「一定是哪行寫錯了」，接著開始漫無目的地修改程式碼，祈禱下一次執行會發生奇蹟。但相信我，作為一名開發者，最重要的基本功不是「寫碼」，而是「除錯（Debug）」。寫程式就像是在森林裡偵察，如果你看不見資料流動的蹤跡，那你永遠只是在黑暗中亂撞。

2. 致命的「保留字」：別讓你的變數名稱成為殺手

在 JavaScript 的世界裡，有些單字是系統「專用」的，我們稱之為「保留字（Reserved Words）」。我常看到初學者為了方便，隨手取一個理所當然的名稱，卻不知道自己已經踩進了地雷區。

根據實戰案例，以下這幾個名稱是導致表單失效的常見元兇：

• cf
• status
• location
• DATCF (這是網友實戰中極具代表性的錯誤命名)

為什麼不能用？因為在瀏覽器環境中，這些字眼往往已經代表了特定的物件或功能。最典型的現象是：當你打開除錯工具觀察變數時，你會發現你的變數竟然顯示為 f（代表 function）或特定的系統物件。

「這就是一般初學者都會遇到的問題，就是變數用到了保留字……這都造成很多錯誤。」

當你的變數被系統誤認成一個「函式」而非「資料」時，後續的處理流程自然會崩潰。養成良好的命名習慣，不僅是為了程式能跑，更是專業開發者的基本素養。

3. 消失的 .value：你傳送的是「內容」還是「空殼」？

另一個讓無數新手卡關的細節，就是忘記加上 .value。這看似微小的差別，卻是「傳送成功」與「傳送失敗」的分水嶺。

讓我們看一段對比：

• 錯誤寫法： 傳送 uid
• 正確寫法： 傳送 uid.value

這兩者在本質上有天壤之別。如果你只傳送 uid，你傳出的是整個「控制項物件（HTML Element）」，在系統眼裡它就是一個複雜的 UI 盒子（Input Control）；而加上 .value，才是伸手進盒子裡取出使用者輸入的那串「資料」。

我常對學生打比方：這就像你要寄一封信，結果你寄出的是整個「郵筒」而不是裡面的「信件」。如果後端接收不到正確的值，請務必先檢查你的變數後方是否漏掉了這幾個關鍵字母。

4. Chrome F12：開發者的「X 光機」

除錯不該靠猜測。如果你不學會使用 Chrome 內建的開發者工具，你永遠無法跨入專業開發者的門檻。

如何像高手一樣啟動偵錯？

1. 按下鍵盤上的 F12。
2. 點選上方標籤中的 Sources。
3. Pro Tip (高手捷徑)： 因為 Google 表單的開發環境檔案眾多，直接用滑鼠找太慢了。請按下 Ctrl+P (Mac 為 Cmd+P)，直接輸入檔案關鍵字（例如搜尋 V 或是與專案相關的檔名）來快速開啟 HTML 或 JavaScript 檔案。

斷點（Breakpoint）：捕捉資料的犯罪現場

在資料準備送出的那一行（通常是 URL 組裝或 API 呼叫前），點擊左側行號設置一個「斷點」。接著執行程式，它會停在該處。此時，請檢查右側的 Local（區域變數） 面板：

• 如果變數顯示為 undefined，代表沒抓到。
• 如果變數顯示為 function 或 input，代表你誤用了保留字或忘了加 .value。
• 只有看到清清楚楚的「字串值」，才代表資料正確流入了。

5. 實戰小技巧：讓資料「自己開口說話」

除了專業的斷點技術，這裡有兩個我私藏的「快速驗證」技巧，能幫你省下大量摸索時間：

• 技巧 A：console.log() 即時監測 在程式碼中插入 console.log(變數名稱)。這是最簡單的「監視器」，讓你能在 Console 面板直接看到變數目前的狀態，確認傳送前資料是否完整。
• 技巧 B：利用 innerHTML 讓 URL 現形 這是一個非常高效率的做法。在網頁下方設定一個隱藏的 <div> 或區域，在執行送出前，利用 innerHTML 將產生的 URL ID 或完整連結秀在網頁上。 為什麼要這麼做？ 因為這能讓你「親眼看見」最終生成的 URL。你可以直接複製這個連結並貼到瀏覽器測試，直接驗證後端（如 Google Apps Script）的 API 是否運作正常，而不需要每次都重新填寫整張表單。

6. 結語：從簡單開始，不要「亂改」

面對錯誤，最忌諱的就是在大規模修改後才發現問題，那會讓你根本分不清是哪一版改壞的。對於初學者，我最誠懇的建議是：「不懂就不要亂改」。

專業開發者的祕密武器是「增量開發」。與其一次加入所有複雜的功能，不如先從最基礎的結構開始，確保基本的資料傳送能成功，再「一個一個功能往上加」。

「你可以不要先加那麼多，然後一個一個加。」

下次當你的程式碼出錯時，你會選擇盲目修改，還是先打開 F12 設置斷點，用數據揭開問題的真相呢？記住，工具在手，你就不再是猜測者，而是掌控全域的開發者。