第一版選擇 GAS + Google Sheets，是為了快速驗證訂餐需求；真實使用後，資料責任與整段訂餐流程的等待問題才逐漸浮現。這一篇不重走遷移故事，而是回頭檢查重新選工具的判斷條件。

現在回頭看，比「哪個平台比較快」更值得問的是：

什麼變化出現時，代表原本合理的工具開始承擔超出原先目標的責任？

這也是這次回顧唯一要回答的問題。

不是做不到，而是責任集合變了

第一版需要的是快速把手機訂餐流程送到使用者手上。到了後來，系統開始同時承擔身份、餘額、歷史、權限、日曆、migration、部署與遠端驗證。

這些責任不是某一天突然一起出現，而是需求一路增加後逐步累積。

因此，重新評估工具的訊號不該只是一支 API 比以前慢，而是：

這和 Day 6 的「為什麼開始想搬」不同。Day 26 要留下的是：什麼訊號值得讓團隊重新打開架構選擇。

換平台，不等於複雜度消失

Workers + D1 成為正式後端後，原本的某些限制確實換了位置，但新的責任也跟著出現。

例如遠端環境要辨識、D1 migration 要確認 target、跨來源請求要處理 CORS、部署與正式資料操作要有明確 authority，驗證也不能只停在本機。

這些內容前面已經分別出現過，這裡不重講細節。它們共同說明一件事：

架構升級不是把複雜度刪掉，而是把複雜度搬到更適合被管理的位置。

Repo 現在把 Worker + D1 定義為唯一正式後端，GAS 只保留歷史回歸與資料來源用途。現行架構契約

這不是「新技術獲勝」的證據，而是系統責任已經換了階段。

比較替代方案前，先確定比較的是同一件事

舊 POC 文件保留了一個很有用的限制：GAS 與 Worker 的效能比較，只能在主要 bootstrap 回應語意一致時成立；缺少必要輸入或回傳內容不等價，就不能拿時間直接比較。舊 POC 比較契約

本篇沒有重新執行 benchmark，也不沿用舊秒數。

真正值得保留的是比較方法：

1. 先說清楚現在反覆付出的成本。
2. 找到能處理同一份責任的替代方案。
3. 先證明兩邊做的是同一件事，再比較時間或操作成本。
4. 把 migration、部署、驗證與後續維護一起算進決策。

如果問題只是一個能局部修正的 query，就先修 query。只有當相同限制反覆出現在核心流程，才值得把架構選擇重新打開。

AI 讓替代方案更便宜，但沒有讓判斷免費

AI 很容易在短時間內做出另一套 POC，這降低了「試另一條路」的成本。

但它也讓錯誤比較更容易發生：兩邊只要少做一點事，就可能看起來更快、更簡單。

所以 AI 協作下真正需要守住的，不是「快速產生替代實作」，而是：

替代方案是否承擔了相同責任，以及遷移後的複雜度是否真的更適合被維護。

這才是 Day 26 和前面文章不同的地方。

本系列實作專案

這是一套持續開發中的便當訂購系統。文章著重「為什麼」，GitHub 保留實際程式碼、文件與演進紀錄。

GitHub：https://github.com/henryfir456/bento-order-app

下一篇會回到一個更小的資料問題：當「儲值方式」開始影響交易語意，它還適不適合只放在自由文字備註裡？