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

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

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

Web App方案為什么讓人崩潰

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

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

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

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

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

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

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

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

npx @mcpher/gas-fakes auth

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

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

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

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

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

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

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

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

憑證安全怎么解

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

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

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

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

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

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

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