Docker 更新網站後怎麼檢查？我的 7 項實際驗證流程

Docker 更新完成，不代表工作已經結束

前幾次修改網站時，我只要看到 Docker 顯示 Started，就會認為部署已經成功。後來實際遇到依賴缺少、文章網址錯誤和頁面模式沒有更新等問題，我才發現容器能啟動，只能證明程式正在執行，不能代表網站的每一項功能都正常。

因此，這次完成普通文章模式和網址調整後，我整理了一套自己實際使用的檢查流程。每次更新網站，我都按照相同順序確認，避免只看首頁正常就結束部署。

第一項：確認 Docker 容器狀態

重新建立網站後，我先檢視應用程式和 MySQL 容器是否都在執行。

正常情況下，應用程式容器會顯示 Started 或 Up，MySQL 則會顯示 Healthy。如果資料庫仍在啟動，網站可能暫時無法讀取文章，所以我不會在容器剛啟動時立刻判定部署失敗。

我這次看到兩個容器都正常執行，才繼續檢查下一項。

第二項：檢視應用程式日誌

容器顯示正常後，我會繼續檢視網站日誌。

這一步很重要，因為有些錯誤不會讓容器停止。例如環境變數缺少、外部服務設定不完整或某個功能初始化失敗，網站首頁仍可能可以開啟，但後臺或部分功能已經出現問題。

我會先找最早出現的明確錯誤，而不是看到大量英文訊息就立刻重複執行部署命令。這次日誌顯示伺服器已在 3000 連線埠執行，網站基本服務正常。

第三項：直接開啟主要頁面

接著，我會在瀏覽器實際開啟以下頁面：

1. 網站首頁。
2. 最新發布的普通文章。
3. 一篇舊圖集。
4. 分類頁面。
5. 後臺文章編輯頁面。

我以前只檢查首頁，但首頁能開啟，不代表文章頁和後臺也能正常使用。這次普通文章與舊圖集採用不同顯示方式，因此兩種內容都必須分別測試。

第四項：確認普通文章沒有分頁

普通文章模式的目標，是讓圖片和文字在同一個頁面連續顯示。

我會從文章開頭捲動到最下方，確認沒有出現 1/3、上一頁或下一頁按鈕，也會檢查每張圖片是否出現在正確段落附近。

舊圖集仍然保留原本的分頁功能。兩種模式不能混在一起，否則新文章看起來仍像圖集，讀者閱讀長文時也容易中斷。

第五項：驗證舊網址的 301 跳轉

我原本的文章使用 /article/01 這類數字網址。發布新文章後，數字編號可能改變，所以我把文章網址改成固定英文程式碼。

修改完成後，我不只在瀏覽器檢視新網址，還檢查舊網址是否返回 301 Moved Permanently，以及新網址是否返回 200 OK。

以 OneDrive 文章為例，舊網址會自動跳轉到：

/article/onedrive-project-storage-transfer

這樣以前分享出去的連結仍然有效，搜尋引擎也能知道文章已永久移到新網址。

第六項：分別檢查電腦和手機

網站在電腦上正常，不代表手機版也正常。

我會用手機實際開啟首頁和文章，檢查：

• 標題是否超出畫面。
• 內文字型是否容易閱讀。
• 圖片是否超出頁面寬度。
• 導覽列是否可以操作。
• 推薦內容是否過大。
• 普通文章是否仍然出現圖集分頁。

這次我曾遇到電腦版正常，但手機點選文章後進入另一篇內容的情況。因此手機測試不能只縮小電腦瀏覽器，而是要用真實手機點選一次。

第七項：測試後臺新增和編輯功能

最後，我會進入後臺建立一篇草稿，確認內容型別中同時有「圖集」和「普通文章」兩個選項。

我也會測試標題、摘要、固定網址、封面、正文圖片和圖片說明能否正常儲存。草稿確認沒有問題後再發布，避免直接拿正式文章測試新功能。

這次新增的普通文章可以連續顯示所有圖片和文字，舊圖集也沒有受到影響，才算完成整次更新。

我現在採用的部署檢查順序

經過幾次實際操作，我目前固定使用以下順序：

1. 部署前備份程式和資料庫。
2. 重新建立 Docker 容器。
3. 確認應用程式為 Up、MySQL 為 Healthy。
4. 檢視應用程式日誌。
5. 測試首頁、文章、圖集、分類和後臺。
6. 驗證舊網址 301 與新網址 200。
7. 使用真實手機再次檢查。
8. 建立草稿測試儲存和發布功能。

這套流程看起來比只看容器狀態多了幾個步驟，但實際上只需要幾分鐘。它能讓我更早發現網址、版面和資料設定問題，也能減少網站更新後才由讀者發現錯誤的情況。

對我來說，部署成功不是終端畫面出現綠色的 Started，而是網站主要功能都經過實際操作，舊內容與新內容也能同時正常使用。