如果選 OAuth 模式（§2 Part D），部署步驟照正確順序走（DNS → Build → Connect → Custom Domain），這一節你永遠不會用到。Pages 模式不需要 Routes，此節不適用。 這是兩個專案各花了 2 小時才學到的教訓。

部署後出問題，從上往下檢查，不要反過來：

真實案例：ming-website 部署後打不開，我們先檢查了程式碼（⑦），查了 2 小時才回頭發現 DNS 沒有 A 記錄（①）。如果按這個順序，5 分鐘就能找到問題。

7.18 手機後台上傳圖片

已自動處理。 public/admin/index.html 內建一段 JS（約 40 行），在所有 Sveltia CMS 檔案上傳之前攔截：圖片 > 1MB → Canvas 壓縮至 1920px / quality 0.8 → 再交給後台上傳。

原圖 8MB → 瀏覽器壓到 ~500KB → 手機 4G 秒傳 → GitHub → Actions 轉 WebP

客戶視角：什麼都不用做。 打開後台、選照片、儲存。不需要壓縮 App，不需要學 Shortcuts 捷徑，不需要用 LINE 中轉。

服務哲學：客戶永遠不用改變他們自己的習慣。是我們要做到他們無須學習成本就能達成。

7.19 Cloudflare Worker / OAuth 除錯

Worker 壞了的三種查法

最常見的三個錯誤

Worker 跟 Pages 的關係（一句話）

Pages 處理靜態網站（你的網頁內容）
Worker 處理 API（OAuth 登入、回呼）
兩者獨立部署，靠 Routes 串接：api/* → Worker，其他 → Pages

[[#table-of-contents|← 回目錄]]

卷三：交付與商業（Business & Operations）

第 8 章：測試與交付檢查

👤 你：照 checklist 驗收、手機/桌面親測 — 🤖 AI：跑自動化腳本、產出驗收報告

8.0 audit.sh — 交付前的最後一道門

前置條件（首次執行前，一次性）：

brew install lychee          # dead link 檢查
chmod +x audit.sh            # 確保可執行

audit.sh 存在於專案根目錄。一個指令，5 階段檢查：

./audit.sh                         # 跑預設網域
./audit.sh https://新客戶.com       # 跑指定網域

目標：5/5 全部通過才能交付。

audit.sh 常見錯誤解析

跑完 audit.sh 後，不用每個紅字都緊張。以下是判定標準：

8.1 全站頁面檢查（自動化）

# 掃描所有 Astro 頁面，檢查是否返回 200
for f in $(grep -l "^---" src/pages/**/*.astro 2>/dev/null); do
  fname=$(echo "$f" | sed 's/src\/pages//' | sed 's/\/index\.astro$//' | sed 's/\.astro$//' | sed 's/\[\.\.\.slug\]//' | sed 's/\[slug\]/test/')
  [ -z "$fname" ] && fname="/"
  code=$(curl -s -o /dev/null -w "%{http_code}" "https://你的網域$fname")
  echo "$code $fname"
done

8.2 手機版檢查（手動）