Google把腳本執(zhí)行鎖了3年，開發(fā)者用1個庫把它撬開了

Google Apps Script（GAS）有個挺別扭的設定：你的代碼明明寫在本地，運行卻必須上傳到Google服務器。這就像買了臺游戲機，每次想玩都得先把光盤寄到廠家，等他們幫你讀盤。

這個痛點存在了多久？從2017年clasp（命令行工具）發(fā)布算起，開發(fā)者忍了8年。期間無數(shù)人試圖在GitHub Actions里直接跑GAS腳本，結果都撞上一堵墻——要么部署Web App（每次改代碼都要重新發(fā)布），要么調用Apps Script API（權限配置復雜到懷疑人生）。

2024年，一個叫gas-fakes的庫出現(xiàn)了。它做的事很簡單：在Node.js環(huán)境里模擬完整的GAS運行時，讓你的腳本以為自己在Google服務器上。

Web App方案為什么讓人崩潰

先說說主流做法的問題。很多團隊用GitHub Actions觸發(fā)GAS，是通過部署Web App實現(xiàn)的——把腳本發(fā)布成一個URL，CI流程里發(fā)HTTP請求調用。

這個流程有幾個暗坑。第一，每次代碼更新后必須重新部署Web App，版本管理完全割裂。第二，你無法在GitHub里直接驗證最新代碼，得兩邊來回切。第三，Web App的權限粒度很粗，要么全開要么全關，敏感操作容易暴露。

一位在Reddit吐槽的開發(fā)者說得直白：「我花了3小時配置OAuth，結果只是為了在CI里改一個單元格的值。」

gas-fakes的解法是把Google Workspace的服務端API包裝成GAS原生對象。SpreadsheetApp.getActiveSheet()這類代碼在Node.js里直接跑，背后實際調用的是Google Sheets API，但你的腳本完全感知不到差異。

15分鐘搭一條本地可跑的流水線

具體怎么操作？核心就兩步：生成ADC（Application Default Credentials，應用默認憑證）憑證，然后在GitHub Actions里注入。

本地初始化用npx最省事，不用全局安裝：

npx @mcpher/gas-fakes init --auth-type adc

npx @mcpher/gas-fakes auth

第一條命令生成憑證文件，第二條完成OAuth授權。之后把憑證內容存進GitHub倉庫的Secrets，CI流程里通過環(huán)境變量注入，gas-fakes會自動讀取。

關鍵點在于：腳本執(zhí)行全程在GitHub Actions的Runner里完成，不需要部署任何Web App，也不需要維護Apps Script API的復雜權限鏈。

這意味著什么？你的版本控制、代碼審查、自動化測試可以真正閉環(huán)在GitHub內完成。改完代碼推PR，CI自動跑一遍，確認沒問題再合并——傳統(tǒng)GAS開發(fā)里這個「跑一遍」的環(huán)節(jié)，以前得手動上傳到Google服務器才能驗證。

誰在用，以及他們省了多少錢

gas-fakes的作者Bruce McPherson是Google Developer Expert，這個庫目前周下載量在npm上穩(wěn)定在2000左右。不算爆款，但在GAS這個細分領域已經(jīng)是最活躍的解決方案。

實際案例里，有個做電商數(shù)據(jù)自動化的團隊分享過：他們把原本部署在Google Apps Script上的訂單處理流程遷移到GitHub Actions+gas-fakes，CI執(zhí)行時間從平均4分鐘降到47秒。主要省掉的是Web App冷啟動和Google服務器端的排隊延遲。

另一個用例是Sheets宏的批量測試。有個財務SaaS團隊需要驗證200多個模板表格的兼容性，以前靠人工抽樣，現(xiàn)在用gas-fakes在CI里全量跑，每次發(fā)布前自動掃一遍。

這些場景有個共同點：不需要Web App的HTTP接口能力，純粹是后臺數(shù)據(jù)處理。恰恰是GAS最擅長的領域，卻被執(zhí)行環(huán)境限制卡了很多年。

憑證安全怎么解

把Google賬號憑證放進GitHub Secrets，聽起來有風險。gas-fakes的ADC方案其實比Web App更安全——憑證只在你本地生成，CI里是一次性環(huán)境變量，不會持久化到任何服務器。

對比Web App方案：那個URL一旦泄露，任何人都能觸發(fā)你的腳本。而gas-fakes的憑證作用域可以精確到單個Sheets文件或Drive目錄，配合GCP的IAM策略，能實現(xiàn)最小權限原則。

有個細節(jié)很多人沒注意到：gas-fakes支持在本地用--dry-run模式跑腳本，不實際調用API，只驗證代碼邏輯。這對CI里的快速反饋很有用，類似單元測試和集成測試的分層。

當然，這個方案也有邊界。如果你的GAS腳本依賴Triggers（時間觸發(fā)器）或UI組件（菜單、對話框），gas-fakes模擬不了，還是得走傳統(tǒng)部署。但對于純數(shù)據(jù)處理、API編排類的腳本，覆蓋度已經(jīng)很高。

Google官方對這類「繞過」工具的態(tài)度一向曖昧。既不阻止，也不支持。clasp當年是社區(qū)項目，后來被Google收編；gas-fakes會不會走同一條路？McPherson在文檔里寫了一句：「這個庫的存在，是因為Google沒提供同等能力的官方方案?！?/p>

如果明天Google突然開放原生Node.js運行時，gas-fakes會立刻變成歷史。但在那之前，它可能是GAS開發(fā)者能拿到的最順手的CI/CD鑰匙。

你現(xiàn)在有多少腳本還卡在「本地改完、手動上傳、祈禱別崩」的循環(huán)里？