最近把自己做的餐廳管理系統正式上線了，趁這個機會分享一下技術架構和踩過的坑。
---
背景
台灣很多中小型餐廳還在用紙本點餐或老舊 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
整個後端零台機器，按用量計費，一間小餐廳一個月的費用幾乎是 $0。
---
前端為什麼不用 React / Vue？
餐廳後台用 Alpine.js SPA，消費者點餐頁也是 Alpine.js。原因很簡單：不需要 build step，wrangler deploy 直接推靜態檔。
一個指令，Worker + 靜態資源全部更新完畢。
---
QR 點餐的安全機制
每次「入座」會產生一個 UUID session token，綁定桌號和餐廳 ID。QR Code 是固定的（不用每次換），但 token 是動態的。
流程：入座 → 產生 session token → 客人掃 QR → 帶 token 驗證 → 進入菜單 → 結帳 → session closed → token 失效
這樣解決了幾個問題：
舊客人的手機掃不回來加點
掃到隔壁桌的 QR 會被拒絕（token 綁 table_id）
忘記結帳 → 4 小時後自動過期
同桌多人掃同一張 QR，系統用 localStorage 的 device_id 區分誰點了什麼，最後合併成一張帳單。
---
廚房出餐狀態機
五個階段：pending → preparing → cooking → ready → served
廚房端只需要一個平板，顯示所有進行中的訂單。消費者端每 10 秒輪詢一次，看到「您的餐點正在烹煮」。
這個輪詢設計是刻意的選擇：WebSocket 在 Cloudflare Workers 上需要 Durable Objects，成本和複雜度不划算，10 秒輪詢對餐廳場景完全夠用。
---
Demo 環境
做了一個完整的互動 Demo，模擬真實餐廳的點餐流程：
https://restaurant.taiwan-fan.com/demo-live.html
業者可以在這裡體驗完整流程再決定要不要申請。
---
目前狀態
Beta 開放中，完全免費
支援：QR 點餐、訂位管理、廚房出餐追蹤、桌位管理、多語言菜單
OAuth 登入：Google / LINE
有興趣的朋友歡迎試用，或留言討論技術細節。
