Google Apps Script Web App 部署：先分清 execute as 與 access 的權限邊界
Google Sheets 綁定的 Apps Script 很適合做小型內部工具，但部署成 Web App 後，真正容易出錯的是權限模型：誰能打開 URL，和程式用誰的身分讀寫資料，是兩個不同問題。若沒有先拆開，常見結果是使用者看得到頁面卻拿不到資料，或是開發者意外讓所有訪客以自己的權限操作資源。
直接答案是：部署前先同時選擇 access（誰可使用）與 execute as（程式以誰的身分執行），再用 /dev 網址和不同權限帳號各測一次。
Web App 最小結構
要發布 Web App，專案需要 doGet(e) 或 doPost(e)，並回傳 HtmlOutput 或 TextOutput：
function doGet() { return HtmlService.createHtmlOutput('ok');}doGet 處理 HTTP GET，doPost 處理 HTTP POST；請勿把敏感資訊放進 query string，並避免使用保留參數名稱 c 與 sid，官方文件指出它們可能導致 HTTP 405。
access 和 execute as 不能混用
在 Deploy → New deployment → Web app 裡，先分別回答兩題：
| 設定 | 決定什麼 | 常見風險 |
|---|---|---|
| access | 哪些帳號能開啟 Web App | 對外開放了不該公開的工具 |
| execute as | 程式以部署者或存取者的身分執行 | 對資料權限作了錯誤假設 |
選擇 Execute the app as me 時，無論誰開啟，程式都以部署者的身分執行。這適合受控流程，但要格外小心 OAuth token；官方明確提醒不要把 ScriptApp.getOAuthToken() 取得的 token 傳到 client。選擇 user accessing the web app 時，每位使用者依自己的身分執行，且可能在 granular OAuth consent 中拒絕部分 scope，因此呼叫服務前應用 ScriptApp.getAuthorizationInfo() 處理缺少授權的情況。
/dev 只用於開發驗證
使用 Deploy → Test deployments 取得的 /dev URL，永遠指向最新儲存的程式碼，但只有 script 編輯者可存取。它很適合在發布前測試，不是可交給一般使用者的測試環境。
正式發布後，分別以部署者、一般已授權使用者與不該有權限的帳號驗證：URL 能否開啟、讀寫的資料是否符合預期、缺少 scope 時是否有明確提示。若轉移到不同網域的 shared drive 或帳號後 Web App 停止運作，官方文件要求由新 owner 或協作者重新部署；這也是交接清單的一部分。
Trigger 的權限也要獨立思考
不要假設 Sheet 的 onEdit 跟 Web App 共用權限。simple trigger 不能存取需要授權的服務、不能存取其他檔案，且最長只能跑 30 秒；installable trigger 則以建立該 trigger 的使用者身分執行。需要跨檔案、寄信或長時間排程時，先確認是 Web App request、simple trigger，還是 installable trigger，才能正確設計錯誤處理與授權流程。
若你的目標是問卷與後續工作流，而非自行維護程式，可先比較 NaraForm 與 Google 表單的使用情境；兩種方案的維運責任不同。
參考資料：
回報錯字、失效連結，或告訴我你想看的延伸主題。