Google Apps Script 費用說明：免費額度與超量計費機制解析

所以，Google Apps Script 到底要不要錢？

嗯...今天要來聊聊那個 Google Apps Script 的費用問題。老實說，這是我最常被問到的問題之一，很多人一聽到可以寫程式自動化處理 Google 的東西，眼睛都亮了，但下一步就是...「欸，這個要錢嗎？」

好，我先直接給個結論：**大部分情況下，Google Apps Script 是免費的**。對，你沒聽錯，免費。你可以用它來串接 Gmail、Google Sheets、雲端硬碟，做一些自動化的工作流程，基本上不用掏一毛錢。

但...人生就是這個「但」最重要。這個免費是有條件的，它的限制叫做「配額」或是「Quotas」。你可以把它想像成，Google 跟你說，餐廳裡的自助吧你可以免費吃到飽，可是你每天只能進來拿 20 次盤子，總共只能吃 1 個小時。你吃得快、拿得精準，那對你來說就是免費；但如果你一直來來回回，或是想在裡面待一整天，那就會撞到牆。

所以，這個問題的核心不是「要不要錢」，而是「你的用法會不會超過免費的額度？」一旦超過，你的腳本就會直接停掉，然後丟出一個錯誤訊息給你看，例如「Service invoked too many times」之類的。

我踩過的坑：一個真實的超額案例

我講個我自己的經驗。之前我幫一個小型電商做一個簡單的庫存提醒系統，就是每天定時跑一次 Google Sheets，檢查哪些商品的庫存低於 10，然後自動寄一封 Email 給倉管人員。

一開始都跑得好好的，很開心。結果有一次他們辦大促銷，商品品項突然暴增好幾百個，然後我的腳本...就掛了。我去看執行紀錄，上面寫著「Execution time exceeded」。啊，原來是這樣。

我這才意識到，我的寫法太天真了。我用一個迴圈一個一個去讀取儲存格、判斷、再記錄。品項一多，整個腳本執行時間就超過了單次執行的上限，Google 就強制把它中止了。免費帳號單次執行上限就是 6 分鐘，一秒都不能多。這就是一個典型的、因為沒有考慮到配額而失敗的例子。

怎麼看懂 Google 的「免費自助吧規則」？

所以，我們要怎麼知道這個「自助吧」的規則...我是說，配額到底有哪些？Google 官方其實有提供一個詳細的配額列表頁面。但老實說，那個頁面對新手不太友善，一堆專有名詞。我把它翻譯成白話文，你主要需要關心這幾大類：

執行總時間 (Triggers total runtime) ：這大概是最重要的。不是指你單一腳本跑多久，而是你帳號下「所有」用觸發器（例如每天定時、每小時定時）自動執行的腳本，加起來的總時間。
單次執行時間 (Script execution time) ：就是我前面提到的，不管你是手動執行還是觸發器，你的腳本從開始到結束，一次不能跑超過 6 分鐘。以前聽說過商業版有 30 分鐘，但現在好像都統一成 6 分鐘了，所以最好以 6 分鐘為準。
服務呼叫次數 (Service invoked too many times) ：這個比較tricky。你每次在程式碼裡寫 `GmailApp.sendEmail()` 或 `SpreadsheetApp.openById()`，都算一次「服務呼叫」。這些特定的服務每天能讓你呼叫的次數是有限的。比如，用 `UrlFetchApp` 抓取網頁資料，免費帳號一天就是 20,000 次。
建立檔案/文件的數量 ：你也不能無限制地用腳本瘋狂建立新的 Google 文件或試算表，這也是有每日上限的。

這些配額是每天重設的，不是月底結算。而且它是從你第一次呼叫服務後的 24 小時開始計算，不是從半夜 12 點喔。

Gmail.com vs. Google Workspace：免費仔與課金玩家的差別

講到這裡，就要提到一個關鍵差異了。你用的帳號是免費的 `@gmail.com`，還是公司或學校付費的 `Google Workspace` (以前叫 G Suite)，你的配額會差很多。這就像免費玩家跟課金玩家的差別待遇。

我整理了一個簡單的比較表，讓你感受一下這個差異。

功能限制	一般免費帳號 (@gmail.com)	付費 Google Workspace 帳號
每日觸發器總執行時間	大概 90 分鐘/天。聽起來很多，但如果你的腳本跑得頻繁，其實一下就用完了。	大概 6 小時/天。這就差很多了，空間大到可以跑一些比較複雜的商業應用。
每日寄信數量 (GmailApp)	100 封/天。拿來做個人通知很夠用，但想做什麼電子報發送就別想了。	1,500 封/天。這個數量級就完全不一樣了，可以做一些小規模的客戶通知。
網址擷取呼叫 (UrlFetchApp)	20,000 次/天。如果你只是偶爾抓個 API，綽綽有餘。	100,000 次/天。要做比較頻繁的資料介接或爬蟲，就需要這個額度了。
單次執行時間	6 分鐘。就是 6 分鐘，沒得商量。	也是 6 分鐘。雖然以前有過 30 分鐘的時代，但現在看起來是拉平了，所以別以為付費就能跑更久。

所以你看，主要的差別在於「每日總量」。Google Workspace 帳戶讓你每天可以做更多的事情。這也很合理，Google 假設你會用在商業用途，自然需要更高的天花板。

萬一真的超量了，怎麼辦？有付費升級的選項嗎？

好，這就是最多人誤會的地方。當你用 Apps Script 超過配額時，會發生什麼事？答案是：**你的腳本會失敗，然後...就沒有然後了。**

Google Apps Script 本身並沒有一個「付錢解鎖更多配額」的按鈕。你不能說「我付 10 美金，讓我今天多寄 500 封信」，這行不通。超過就是超過，只能等隔天配額重設。

那如果我的應用真的需要突破這個限制，該怎麼辦？這時候，Google 會希望你走向更專業的道路，也就是使用 `Google Cloud Platform (GCP)`。

你可以把 Apps Script 看作是 Google 提供的一個方便的、輕量級的自動化工具。但當你的需求成長到一定規模，它就像在跟你說：「嘿，你長大了，該去外面更專業的雲端平台闖蕩了。」你可以把需要大量運算或 API 呼叫的部分，改寫到 GCP 的服務上（例如 Cloud Functions 或 Cloud Run），然後讓 Apps Script 去呼叫它。這樣一來，計費方式就會變成 GCP 的用量計費，那又是另一個世界了。

常見錯誤與修正：如何跟配額和平共處？

其實，大部分人會撞到牆，都不是因為用量真的那麼大，而是程式寫法不夠好。這裡有幾個我學到的教訓，可以讓你活得久一點：

錯誤：在迴圈裡重複讀寫儲存格。
這是我前面犯的錯。`for` 迴圈跑 1000 次，就呼叫了 `getValue()` 1000 次，超慢又浪費配額。
修正：使用批次處理 (Batch Operations)。 一次把整個範圍的資料用 `getValues()` 讀進來，變成一個二維陣列。在記憶體中處理完所有邏輯判斷，最後再用 `setValues()` 一次性寫回去。這樣只算兩次服務呼叫，天差地遠。
錯誤：把所有事情都擠在一個腳本裡一次做完。
很容易就超過 6 分鐘的單次執行上限。
修正：拆分任務，用觸發器接力。 比如，你可以讓第一個腳本跑 5 分鐘，處理前 500 筆資料，然後在結束前建立一個新的觸發器，讓它 5 分鐘後再執行第二個腳本，繼續處理剩下的資料。這需要用到 `PropertiesService` 來記錄目前處理到哪裡了。
錯誤：太頻繁地呼叫外部 API。
例如每分鐘都去抓一次天氣資料，很快就會用完 `UrlFetch` 的配額。
修正：善用快取 (CacheService)。 把 API 回傳的結果用 `CacheService` 暫存起來，設定一個例如 30 分鐘的過期時間。在這 30 分鐘內，所有需要這份資料的執行緒，都直接從快取讀取，而不是真的跑去呼叫外部 API。