昨天先做到送出網站建置，今天接著確認建置結果，再把 WorkCafe 部署到 Cloud Run。這次已取得公開 HTTPS 網址，首頁能顯示地圖與店家卡片。
這篇依實際操作順序整理：確認映像、部署服務、設定正式網址，再測試網站。Cloud Run 執行 Laravel＋Inertia＋React，店家資料仍放在 Firestore，由 Laravel 透過 REST API 讀取。
截圖記錄了部署版本、首頁、篩選與零結果畫面，也保留瀏覽器警告和伺服器日誌。尚未完成的驗證放在文末。

1. 先確認昨天的建置結果

1. 開啟 Google Cloud Console，選擇 Day 28 使用的專案。
2. 進入「Cloud Build → 記錄（History）」，按開始時間找到昨天送出的那筆建置。
3. 查看狀態與日誌：進行中就繼續等待；顯示 SUCCESS 才往下做。FAILED 或 TIMEOUT 代表尚未完成，先查看出錯步驟並修正。
4. 進入「Artifact Registry → workcafe-repo → workcafe-app」。
5. 找到這筆建置使用的日期時間標籤，記下映像 URI 與 digest，部署時選同一個版本。

建置成功代表網站已打包成容器映像，還沒有公開網站網址。下一步才是讓 Cloud Run 執行它。

2. 建立 Cloud Run 服務

2.1 選擇映像與執行設定

1. 進入「Cloud Run → 服務」，按「部署容器（Deploy container）」。
2. 選擇部署既有容器映像，開啟映像選擇器。
3. 選取 workcafe-repo 中的 workcafe-app，指定上一節確認的版本。
4. 依下列項目核對服務設定。

• 服務名稱：workcafe-app。
• 區域：asia-east1，與 Day 28 的容器儲存庫一致。
• 存取方式：本次是公開網站，設定允許公開存取；組織政策若不允許，先處理權限。
• 執行身分：在安全性設定中，選取 workcafe-runtime 對應的完整服務帳戶地址。
• 容器連接埠：8080，程式監聽 0.0.0.0 的 PORT。
• 計費模式：依請求計費。
• CPU：1。
• 記憶體、執行個體上限與請求逾時：部署前逐項核對，並記錄實際值。

Day 28 原先建議 1 GiB 記憶體、最小 0／最大 2 個實例與 60 秒逾時；這次修訂版本截圖顯示的是 512 MiB、修訂版本執行個體數上限 20，以及 300 秒逾時。兩者不同，因此不能把原先建議寫成已套用。最小實例數與服務層級的上限仍需另外核對；實例數上限也不是帳單金額上限。

2.2 填寫環境變數

開啟容器的「變數與密鑰」，逐筆新增：

2.3 接上 APP_KEY，送出部署

沿用 Day 28 建立的 workcafe-app-key，不重新產生金鑰：

1. 確認執行服務帳戶已選為 workcafe-runtime。
2. 開啟容器的「變數與密鑰」設定。
3. 選擇「參照密鑰」。
4. 環境變數名稱填入 APP_KEY。
5. 密鑰選擇 workcafe-app-key。
6. 版本選擇 1。
7. 核對本節其他設定後，按「部署」。

Cloud Run 會讀取指定的密鑰版本，透過 APP_KEY 環境變數提供給 Laravel。之後更新網站保留相同設定。Firestore 使用服務帳戶身分取得 ADC，不填本機 JSON 檔案路徑。
Laravel 設定快取必須在執行環境變數與 secret 到位後建立，不能帶入本機或建置階段的設定快取。

3. 取得網址，補齊來源限制

1. 第一次部署完成後，在服務詳細頁複製 HTTPS 網址。
2. 按「編輯及部署新修訂版本」。
3. 在環境變數中新增 APP_URL，值填剛才複製的完整 HTTPS 網址。
4. 保留原本映像與 APP_KEY 密鑰參照，按「部署」。
5. 等待這次設定更新產生的新修訂版本就緒。

接著到 Maps 瀏覽器金鑰的網站限制，加入這個正式來源，例如 https://你的服務網址/，並保留必要 API 限制。若本次確實公開 Firebase Auth 登入，再將正式網域加入授權網域；尚未啟用的功能不列為已驗證。
若只是調整金鑰允許的來源，不必因此重建前端；若更換 VITE_ 的值，就需要重新建置映像。

4. 先驗證服務，再記錄發布結果

修訂版本（revision）是 Cloud Run 每次部署留下的版本紀錄。確認最新版本就緒、流量指向本次版本後，依序檢查：

1. 開啟「正式網址/up」，確認 HTTP 狀態為 200。可在瀏覽器開發者工具的 Network 查看狀態。
2. 開啟正式網址首頁，確認店家卡片與地圖載入。
3. 開啟「正式網址/test/work-score」，確認回傳 404，沒有出現本機測試頁。
4. 回到 Cloud Run 日誌，查看剛才這段操作是否出現錯誤。

/up 成功代表應用健康檢查通過；首頁能否讀取 Firestore，要另外核對店家資料與日誌。
這次首頁截圖已顯示地圖、店家卡片與示範資料標示。/up 與 /test/work-score 的狀態仍需要各自的請求紀錄，不能用首頁載入成功代替。
記錄此次 revision、映像版本與測試時間。既有服務保留前一個可用 revision，必要時把流量切回；第一次部署尚無可回復版本，失敗時先停止發布並修正。

📸 圖片 1-1｜Cloud Run 修訂版本就緒並承接 100% 流量

📸 圖片 1-2｜公開 HTTPS 網址顯示地圖與店家卡片

Cloud Run 的版本更新不會自動清除使用者瀏覽器的 PWA 快取。公開網址的互動、離線與更新流程，接著分別測試。

5. 在公開網址重新跑主流程

先用新的瀏覽器工作階段測一次，避免本機或舊版快取影響判斷。

首頁顯示五間示範店家；選取「插座多」後，清單剩下兩間。搜尋 zzzz-no-match-29 時，清單顯示零間店家與清除搜尋入口，地圖上的店家標記也不再顯示。
地圖標記仍依現有資料映射核對，沒有標記的店家不直接算成這次部署造成的問題。

📸 圖片 2-1｜選取「插座多」後的兩間店家與地圖標記

📸 圖片 2-2｜搜尋無符合店家時的零結果提示

PWA 必須在公開來源重新測試。localhost 的安裝與快取不會自動變成正式網站的驗證紀錄；Android 模擬器可以繼續使用，但要直接開啟公開 HTTPS 網址，並清楚記錄測試裝置。

6. 對照瀏覽器紀錄與 Cloud Run 日誌

跑完指定流程後，核對同一段時間的瀏覽器 Console、Network 與伺服器日誌。若有錯誤，記下操作步驟、請求狀態與處理結果，不只截一個剛清空的 Console。
用量也一起看：Maps 請求、Firestore 讀取及主機資源是否符合這輪測試。若沒有呼叫 AI，就不把 AI 用量寫成已驗證；也不要為了截圖額外送出請求。部分監控資料有延遲，沒有立即出現數字時先記錄待確認。

📸 圖片 3-1a｜地圖點擊紀錄與 Console 待處理警告

Console 留下了地圖標記點擊紀錄，也出現兩項警告：地圖事件監聽方式需要調整，以及正式網域尚未加入 Firebase OAuth 授權。登入功能因此仍待處理與驗證，這張圖不能解讀成「所有功能都正常」。

📸 圖片 3-1b｜正式首頁的 GET 請求與 Service Worker 200 回應

Network 顯示首頁 GET 請求回傳 200 OK，並標示 from service worker。這代表瀏覽器收到經 Service Worker 處理的回應，不能單靠它判定 Cloud Run 直接回應成功，也不能據此認定首頁來自快取。

📸 圖片 3-2｜Cloud Run 日誌中的首頁與靜態資源 200 回應

Cloud Run 截圖可見首頁、sw.js 與圖示等請求的 200 紀錄，補上了伺服器端的觀察。這些紀錄只涵蓋畫面中的時段與請求，尚不足以確認所有路由或 Firestore 權限都已驗證。
瀏覽器截圖使用 Chrome 的 iPhone 16 尺寸模擬，屬於桌面瀏覽器測試，不是 iPhone 實機測試。
整理紀錄時，可以把已移除敏感資訊的附件交給 Agent 核對：

請依附件整理 WorkCafe 發布驗證結果。
逐項列出測試流程、可見結果、錯誤與未驗證事項。
區分平台發布成功、首頁載入成功、互動測試與 PWA 測試。
不可把空白 Console 當成整站沒有錯誤，
不可把 Android 模擬器寫成實體手機。
沒有證據的項目保留待驗證；未公開功能標為不適用。
不要修改程式、部署、呼叫 API、commit 或 push。

實作到這裡，留下成果與限制

WorkCafe 已從本機開發走到公開網址，Cloud Run 修訂版本承接 100% 流量。這次記錄了首頁載入、插座篩選、零結果提示，以及瀏覽器與伺服器端的回應，作為這個版本的實作成果。
這個版本仍有清楚的限制：Console 保留地圖事件監聽與 OAuth 網域警告，部署資源設定也與原先建議不同。/up、測試路由 404、導航、正式來源的 PWA 離線與恢復、版本更新、實體手機測試及用量，未有完整紀錄的部分都不列為已通過。
這個系列的實作就收在這裡。從需求、介面、資料處理到部署，WorkCafe 已成為能透過公開網址開啟的網站；做到了什麼、哪些地方還有限制，也一併留下紀錄。Day 30 會回顧這段開發過程、工具使用與學到的事，為整個系列收尾。

參考：Cloud Run 容器部署、Cloud Run 密鑰設定、Cloud Run 服務身分。