沒有常駐程序：跟一般伺服器最大的差別

Apps Script 跟一台伺服器最根本的差別是沒有一個常駐、屬於你的程序。一般伺服器是一支持續執行的程式，開機後一直在記憶體裡等請求；Apps Script 的程式碼平時不執行，只在被觸發（有人打 web app 網址、觸發器到點、你手動按執行）時才啟動一個執行實例，跑完就結束。這個模型帶來幾個要先知道的取捨：

• 不必管主機：沒有作業系統要維護、沒有開關機、沒有閒置費用。程式碼不跑時完全不佔資源。
• 每次執行是獨立的：兩次執行之間，記憶體裡的變數不會保留。要跨執行記住東西，得寫進外部儲存（Sheet、PropertiesService、Drive）。這跟伺服器可以用行程內記憶體 cache 是相反的。
• 有執行上限：單次執行最長 6 分鐘、同時併發有數量限制。長時間或高併發的工作不適合，細節見執行配額。

理解「沒有常駐程序」才知道 Apps Script 適合什麼：短、偶發、由事件觸發的工作，例如「接一則 beacon 寫一列」「每天彙總一次」。不適合的是需要持續連線、低延遲、或狀態常駐記憶體的服務。

容器綁定 vs 獨立專案

Apps Script 專案有兩種存在形式，差別在「它跟一個 Google 檔案綁不綁定」。

容器綁定（container-bound） 的專案依附在一個具體檔案上——從某張試算表的 擴充功能 → Apps Script 開出來的專案，就綁定那張試算表。它的好處是程式裡用 SpreadsheetApp.getActiveSpreadsheet() 直接拿到那張表，不必記檔案 ID；流量統計用這種，程式跟資料表天生綁在一起，最省事。它也能存取容器檔案特有的事件（例如試算表的 onEdit、表單的 onFormSubmit）。

獨立專案（standalone） 不依附任何檔案，從 script.google.com 直接建立。它適合「不特別綁一個檔案」的工具，或要跨多個檔案操作的情境；存取試算表要用 SpreadsheetApp.openById("表的ID") 明確指定。

選擇判準很直接：這段程式主要就是服務某一個檔案嗎——是（流量統計服務那張 log 表），用容器綁定；否（一個要操作很多表的通用工具），用獨立專案。

用到的服務

Apps Script 透過一組內建服務物件操作 Google 資源，這個案例會碰到的主要是：

• SpreadsheetApp：讀寫試算表，appendRow、getRange 等，是資料的儲存層（模組三詳談）。
• ContentService：產生 web app 的回應內容，doPost 必須回傳它的輸出。
• ScriptApp：管理觸發器，時間排程彙總會用到（模組四）。
• PropertiesService：存少量 key-value 設定或狀態，適合放「上次處理到哪一列」這種跨執行要記住的小資料。

這些服務都以你的 Google 帳號身分執行、受你的授權範圍約束，授權模型是下一篇web app 部署模型的主題。

下一步

知道 Apps Script 是什麼之後，要讓它能被 blog 的 beacon 打到，得把它部署成有公開網址的 web app。部署模型、doGet/doPost、以及授權流程，見web app 部署模型。

doGet 與 doPost：兩個進入點

web app 對外的行為由兩個特殊函式定義。收到 GET 請求時，Google 平台呼叫 doGet(e)；收到 POST 請求時呼叫 doPost(e)。參數 e 帶著請求內容：doGet 從 e.parameter 拿 query string，doPost 從 e.postData.contents 拿請求主體。流量統計的 beacon 用 sendBeacon 送 POST，所以接收端實作 doPost，從 e.postData.contents 讀那串 JSON 字串。

兩個函式都必須回傳一個 ContentService 或 HtmlService 的輸出，這是平台的硬性要求——不回傳會被當成執行沒有正常結束。詳細用法見知識卡 doGet / doPost。

值得先記住的一條限制是 Apps Script 沒有 doOptions，所以它無法回應跨網域請求的 CORS preflight。這條限制決定了前端 beacon 必須用不觸發 preflight 的方式送，是前端 beacon 與 CORS 障礙的核心。

exec 與 dev：兩種網址

部署 web app 後會遇到兩個結尾不同的網址，用途不一樣，搞混會在測試時卡住。

/exec 是正式版網址：它對應你「部署」的那個版本、網址固定不變、遵守你設定的「誰可以存取」。blog 的 beacon 要填的是這個。/dev 是測試版網址：它永遠對應編輯器裡最新存檔的程式碼（不必重新部署就生效），但它只有對這個專案有編輯權的人（也就是你，登入狀態下）能存取。/dev 適合你自己邊改邊測，/exec 才是給匿名訪客用的。

因為 /dev 要登入、/exec 才允許匿名，用 /dev 當 beacon 端點會讓所有沒登入的訪客都被擋掉——這是一個容易誤用的點。beacon 一律用 /exec。

更新部署為什麼要用同一個網址

改完程式後怎麼讓 /exec 反映新版本，是另一個容易出錯的地方。Apps Script 有兩個看起來都能「部署」的入口：新增部署作業 會產生一個全新的 /exec 網址；管理部署作業 → 編輯 → 版本選「新版本」 則是把既有部署更新到新程式碼、網址不變。

正確做法是後者：第一次用「新增部署作業」拿到網址、填進 blog；之後每次改程式，都用「管理部署作業」更新同一個部署。如果每次都「新增部署作業」，會不斷產生新網址，而 blog 裡填的還是舊網址、指向舊版本的程式，於是「我明明改了程式怎麼沒生效」。記住這條分工，就避開了這個常見的假故障。

首次授權與未驗證警告

第一次部署（或第一次執行會存取你資料的程式）時，Google 會要求授權，流程中會出現一個「Google 尚未驗證這個應用程式」的警告畫面。這個警告是正常的：它出現的原因是這支腳本是你自己寫的、沒有經過 Google 的應用程式審核，而不是因為程式有問題。走「進階 → 前往（專案名稱）」繼續、再「允許」授予它存取你試算表的權限，就完成授權。

授權授予的範圍只涵蓋程式實際用到的服務（這個案例是那一張試算表），不會給到你其他的 Google 資料。之後這支 web app 以你的身分執行，能做的事就是 doPost 裡寫的那些。

下一步

部署模型清楚後，就能把接收端實際做出來、部署、收到第一筆瀏覽——見模組二：接收端 handler。部署設定「誰可以存取」的安全含義，見模組五。