最近把自己做的餐廳管理系統正式上線了，趁這個機會分享一下技術架構和踩過的坑。

背景

台灣很多中小型餐廳還在用紙本點餐或老舊 POS，換系統的門檻很高。我想做一個
不需要安裝任何 App、不需要特殊硬體、一台 iPad 就能跑起來的餐廳管理平台。

系統叫 Tablee，官網：https://restaurant.taiwan-fan.com/

技術選型

為什麼選 Cloudflare Workers + D1？

一開始考慮過 GCP Cloud Run + MySQL，但餐廳這個場景有個特性：
流量非常不平均，午餐晚餐各爆一次，其他時間幾乎閒置。

Serverless edge 完美符合這個需求：

• Workers：請求到來才執行，沒有冷啟動費用
• D1：SQLite-based，小餐廳的資料量完全夠用
• KV：拿來存 session state、OAuth state、rate limit counter
• R2：菜單圖片 CDN，搭配 cdn.taiwan-fan.com 自訂域名

整個後端零台機器，按用量計費，一間小餐廳一個月的費用幾乎是 $0。

前端為什麼不用 React / Vue？

餐廳後台用 Alpine.js SPA（hash routing），消費者點餐頁也是 Alpine.js。
原因很簡單：不需要 build step，wrangler deploy 直接推靜態檔。

這讓部署流程極度簡單：

npx wrangler deploy

一個指令，Worker + 靜態資源全部更新完畢。

---
QR 點餐的安全機制

這是整個系統最核心的設計。

每次「入座」會產生一個 UUID session token，綁定桌號和餐廳 ID。
QR Code 是固定的（不用每次換），但 token 是動態的。

入座 → 產生 session token（UUID）
客人掃 QR → 帶 token 驗證 → 進入菜單
結帳 → session closed → token 失效

這樣解決了幾個問題：
- 舊客人的手機掃不回來加點
- 掃到隔壁桌的 QR 會被拒絕（token 綁 table_id）
- 忘記結帳 → 4 小時後自動過期

同桌多人掃同一張 QR，系統用 localStorage 的 device_id（UUID）區分誰點了什麼，
最後合併成一張帳單。

---
廚房出餐狀態機

五個階段：pending → preparing → cooking → ready → served

廚房端只需要一個平板，顯示所有進行中的訂單。
消費者端每 10 秒輪詢一次，看到「您的餐點正在烹煮」。

這個輪詢設計是刻意的選擇：WebSocket 在 Cloudflare Workers 上需要 Durable Objects，
成本和複雜度不划算，10 秒輪詢對餐廳場景完全夠用。

---
多語言 i18n

行銷網站支援繁中 / 英文，用 path prefix 做：
- /zh/ → 繁體中文
- /en/ → 英文

Worker 根據 Accept-Language 302 到對應路徑，爬蟲直接拿 index.html。

字典用 JSON 檔管理，前端用 data-i18n attribute 動態替換。

---
Demo 環境

做了一個完整的互動 Demo，模擬真實餐廳的點餐流程：

👉 https://restaurant.taiwan-fan.com/demo-live.html

業者可以在這裡體驗完整流程再決定要不要申請。

---
目前狀態

- Beta 開放中，完全免費
- 支援：QR 點餐、訂位管理、廚房出餐追蹤、桌位管理、多語言菜單
- OAuth 登入：Google / LINE

有興趣的朋友歡迎試用，或留言討論技術細節。