Staging Push 可以把測試站的檔案或資料庫變更送到正式站，但推送後若出現版面錯誤、外掛相容性問題或資料遺失，處理順序十分重要。本文示範如何先查看推送範圍、建立回退點，再按檔案或資料庫逐項驗證。示範截圖中的網域、IP、帳戶、電郵、伺服器及應用程式資料均已遮蔽。
回滾前先停止更多變更
發現問題後先暫停新的部署、內容更新和外掛安裝，記錄事故時間及受影響功能。不要在未保存現況前再次推送，否則會覆蓋重要證據。
步驟 1：開啟 Push 入口及查看來源
確認目前在正確的 Staging 應用程式，查看來源和目的地標籤。公開筆記只使用「測試站」和「正式站」示範值，不保留真實網域或應用程式名稱。
步驟 2：選擇檔案或資料庫範圍
核對問題屬於檔案、資料庫或兩者。若只是 CSS、主題或外掛檔案，避免覆蓋近期訂單資料；若資料庫結構有問題，先在獨立副本重現。
步驟 3：確認資料庫表格影響
列出會被覆蓋的表格，特別注意訂單、會員、表單和自訂資料。任何帳戶識別資料、電郵或 token 都不要放進公開截圖；只保留表格類型和匿名數量。
步驟 4：建立推送前回退備份
在執行回滾或再次推送前建立按需備份，並確認備份完成。記錄備份時間和預計還原點，讓團隊知道哪個版本是事故前基線。
步驟 5：覆核並確認回滾操作
逐項查看檔案模式、資料庫模式、備份狀態及預估影響，再確認操作。不要在高峰時段或付款進行中執行；必要時先開啟維護頁面並通知團隊。
步驟 6：查看日誌並驗證網站
回滾完成後查看部署和錯誤日誌，測試首頁、登入、表單、付款、媒體、Cron 和 API。保留回滾前後的狀態，至少觀察一個高峰週期才恢復正常部署節奏。
常見問題：回滾是否一定要覆蓋資料庫？
不一定。若問題只在程式碼或樣式，先只回退檔案；覆蓋資料庫前要確認沒有新的訂單、會員或內容會被一併刪除。
常見問題：回滾後仍有錯誤怎麼辦？
比較回滾前後日誌、快取和 PHP 版本，並確認 CDN 或外部 API 沒有保留舊狀態。不要連續執行多次回滾而不保存每次結果。
總結
安全回滾的核心是「停止變更、界定範圍、建立備份、覆核摘要、觀察日誌、逐項驗證」。只要把資料庫和檔案分開判斷，就能減少不必要的資料覆蓋。
