WordPress Recovery Mode 是核心內建的嚴重錯誤保護功能。當一般頁面載入發生致命 PHP 錯誤時，系統可能寄出一條專用登入連結，暫停造成問題的外掛或主題，讓管理員重新進入後台。它是臨時診斷通道，不代表錯誤已永久修復。
先辨認嚴重錯誤情境
常見徵狀包括網站顯示 technical difficulties、更新後白畫面、前台不能載入或後台立即中斷。先記錄出錯時間、剛完成的更新和受影響網址，不要連續隨機停用多個元件。
檢查管理員電郵
WordPress 會把 Recovery Mode 連結寄到網站管理員電郵，內容通常包含出錯元件和錯誤摘要。檢查垃圾郵件、隔離區及主機寄信記錄，並確認網站設定的管理員地址仍有效。
理解專用連結的作用
連結會建立只屬於該管理員工作階段的 Recovery Mode。造成錯誤的外掛或主題可能只在這個工作階段暫停，正常訪客看到的狀態未必相同，因此不能把能進後台當成網站已恢復。
登入後查看錯誤通知
後台會指出哪個元件被暫停。記下外掛或主題名稱、版本、錯誤檔案和行數，再比對最近更新。若通知指向自訂程式碼，先把修改內容與上一個可用版本比較。
先採取最小變更
停用確定出錯的元件，或還原該元件到已驗證版本。不要同時更新核心、替換主題和清除資料庫，否則網站恢復後亦難以確認真正原因。
在 staging 重現問題
把相同核心、PHP、外掛和主題版本複製到測試環境，重做觸發步驟。查看完整錯誤日誌，確認是版本不相容、缺少函式、記憶體不足或自訂程式錯誤，再決定修補方案。
修復外掛衝突
若錯誤在更新後出現，檢查外掛更新紀錄和最低 PHP 或核心要求。可先停用問題外掛維持網站運作，等待修正版或由開發者修補；不要直接修改外掛核心檔案。
修復主題或 functions.php
自訂程式碼錯誤可令整站失效。從備份或版本控制還原最近改動，並以子主題或自訂外掛重新實作。避免在正式後台編輯器內試錯，因為語法錯誤可能再次鎖死網站。
電郵收不到時改用主機工具
若 Recovery Mode 電郵沒有送達，可透過 SFTP、SSH 或主機檔案管理器暫時重新命名可疑外掛目錄。只處理已懷疑的元件，保存原名稱，方便修復後恢復。
安全啟用錯誤日誌
在 staging 或短時間診斷時啟用 `WP_DEBUG_LOG`，並關閉前台錯誤顯示，避免路徑和程式資訊暴露給訪客。完成排查後關閉除錯，保護及清理日誌。
檢查 PHP 與資源限制
致命錯誤不一定來自程式語法，也可能是 PHP 版本不相容、記憶體耗盡或缺少擴充。比對主機錯誤日誌、Site Health 和外掛要求，再調整環境或程式。
驗證前台與關鍵流程
修復後測試首頁、文章、登入、表單、搜尋、購物車、結帳、排程和 REST API。清除快取並使用未登入瀏覽器重測，確保不是 Recovery Mode 工作階段掩蓋問題。
正確退出 Recovery Mode
確認問題元件已停用、修補或還原後，才從管理列退出 Recovery Mode。退出後再次測試相同頁面；若錯誤重現，重新查看日誌，不要反覆按退出掩蓋根因。
改善管理員電郵可靠性
Recovery Mode 依賴管理員收信。設定可靠 SMTP、寄件網域驗證和外部監察，並定期測試系統郵件。保留另一個主機層管理通道，避免網站寄信故障時完全失去復原入口。
建立事故復盤
記錄觸發原因、受影響時間、臨時措施、永久修復和預防動作。把高風險更新先放到 staging，保留可還原備份和版本清單，讓下一次錯誤能更快定位。
參考資料
[WordPress 官方：Recovery Mode](https://wordpress.org/documentation/article/recovery-mode/)
[WordPress 官方：Debugging in WordPress](https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/)
