後台一打開只剩一片白，前台也跟著消失，連登入頁都按不下去——這是 WordPress 站長最熟悉的惡夢場景。白畫面（White Screen of Death，WSoD）多半是 PHP 致命錯誤把整個程式攔在輸出第一個位元組之前，常見肇因落在外掛之間互踩、外掛吃不下新版 PHP、或是主題本身出狀況。

問題是症狀都長一樣，根因卻可能差了十萬八千里。沒有一套標準流程把可能的源頭逐層剝開，就只能猜，猜錯一次又得重來一輪。下面這套 wordpress 外掛衝突排查的流程，把後台還能進、後台已經進不去兩種情境一起涵蓋，5 個步驟跑完，多半就能鎖定肇事者。

白畫面背後通常是哪一層在叫

白畫面之所以難解，是因為它把錯誤訊息也一併吞掉了。預設情況下 WordPress 不會把 PHP 錯誤直接吐到瀏覽器，加上多數主機都關掉 display_errors，使用者看到的就是純白頁，連線索都沒有。要排查衝突，第一件事是讓錯誤訊息現形。

肇因大致落在四個區塊。外掛之間爭奪同一個 hook 或函式名稱，常見於兩款功能重疊的快取或 SEO 外掛同時啟用。外掛內部寫法在新版 PHP 失靈，像是 PHP 8.x 收緊型別、移除舊函式，會讓老外掛直接致命。佈景主題（Theme）的 functions.php 出錯，影響範圍跟外掛一樣大。PHP 記憶體不足，這類錯誤訊息通常會明寫 Allowed memory size exhausted，相對好認。

把這幾層釐清，下一步就知道排查順序怎麼排——從最常見、影響範圍最大的外掛衝突開始，逐層往主題、PHP 環境收斂。

5 個步驟把 wordpress 外掛衝突排查跑完

下列 5 個動作彼此有順序關係，前一步沒做完不要跳到後面。每一步都先讓問題現形或縮小範圍，再進入下一步。如果是線上正式站，先把整套流程搬到測試環境（Staging）跑，避免訪客看到中途狀態。

開啟 debug 模式攔截錯誤訊息

打開 wp-config.php，找到 define( 'WP_DEBUG', false ); 那一行，改成下列三行寫法。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

第一行打開除錯，第二行把錯誤訊息寫到 wp-content/debug.log，第三行避免錯誤直接吐到前台讓訪客看到。儲存後重新整理出問題的頁面，再用 FTP 或檔案總管下載 debug.log 開來看。最關鍵的字串是 Fatal error，那一行會明寫是哪個檔案、第幾行、哪一個函式出狀況，多數時候光看路徑就能認出是哪一支外掛。

如果 debug.log 完全沒寫東西，可能是錯誤發生在 WordPress 載入之前，這時要回頭看主機後台的 PHP error log（cPanel／Plesk／主機商面板都有，路徑通常是 ~/logs/error_log）。另外，現代外掛衝突也有不少落在 JavaScript 端，PHP 日誌抓不到，前台白頁時順手按 F12 打開瀏覽器開發者工具，看 Console 紅字一起判讀。

用二分法停用外掛縮小範圍

確認是外掛層級的問題後，下一步是找出究竟是哪一支。最有效率的作法是二分法，比逐一停用快得多。

進不了後台時，用 FTP 連到 wp-content/plugins/，把整個 plugins 資料夾改名成 plugins_off，WordPress 會自動把全部外掛停用。確認白畫面消失後，把資料夾名稱改回 plugins，所有外掛仍是停用狀態，這時逐一啟用，每次啟用後重新整理首頁與後台，直到白畫面再現，那一支就是嫌疑犯。

如果裝了 20 支以上的外掛，逐一啟用太慢，改走二分法——先啟用前一半，沒事就再啟用剩下一半的前一半，有事就停掉這一半再啟用另一半，每輪砍掉一半的可能性。20 支外掛大約 5 輪內就能鎖定。鎖定後不要急著刪，先把該外掛單獨停用、其他全開的狀態下重現一次，確認真的是它，再考慮換版本、回報作者或找替代品。

切換預設佈景排除主題干擾

如果整批外掛停掉、白畫面還在，問題就不在外掛這一層，要往主題排查。最快的方式是切到當年的官方預設佈景（2026 年是 Twenty Twenty-Six），確認問題是否消失。

後台還能進的情況下，直接到「外觀 → 佈景主題」切換。後台進不去就用 phpMyAdmin 進 wp_options 資料表，把 template 與 stylesheet 兩列的值改成 twentytwentysix（或主機已內建的任一預設佈景代號）。也可以用 FTP 把 wp-content/themes/ 底下出問題的主題資料夾改名，WordPress 找不到原主題會自動退回預設佈景。

切換後白畫面消失，就確定是主題的 functions.php 或某個範本檔案出錯。常見元兇是子主題（Child Theme）裡舊版自訂程式碼使用了 PHP 8.x 已移除的寫法，或是主題作者升級主檔案時改了 hook 行為。先把該主題的 functions.php 開來看 debug.log 指到的行數，多半改一行就能修好。

檢查 PHP 版本相容性

外掛跟主題都沒事，但白畫面在主機商升級 PHP 之後才出現，那衝突點就在 PHP 版本。2026 年主流主機商預設都已推到 PHP 8.3 或 8.4，部分先進主機甚至開放 PHP 8.5。版本越新效能越好，越老的外掛卻越容易在新環境失靈。

到主機後台把 PHP 切回上一個次版本（例如從 8.4 退回 8.3 或 8.2），重新整理確認白畫面是否消失。會消失就確定是版本相容問題，這時不要長期停在舊版本——PHP 8.3 將於 2027 年 12 月進入支援終止（End of Life），舊版會逐漸收不到安全更新。

正確作法是裝一支靜態掃描外掛先盤點問題。「Plugin Compatibility Checker」這款可以掃到 PHP 8.5，會列出每支外掛使用了哪些已棄用或已移除的函式，照清單去找替代外掛或更新版本。掃完該換的換、該下架的下架，再把 PHP 推回最新穩定版。

翻 error log 對照堆疊

前面 4 步通常能解決 8 成以上的白畫面，剩下的 2 成需要更細的線索——通常是兩支外掛在特定情境下才衝突，單獨啟用都沒事，組合起來才出狀況。

這時 Query Monitor 是必裝的工具。它會把每一次頁面請求的 PHP 錯誤、PHP 警告、慢查詢、HTTP 請求、模板載入順序、hook 觸發次序全部列出來，並標註是哪支外掛觸發的。配合 wp-content/debug.log 的歷史紀錄，把出問題的請求路徑跟它的堆疊（Stack Trace）對起來看，就能定位到兩支外掛在哪個 hook 上互相覆寫。

要更細的監控可以另外打開 SAVEQUERIES 常數，把每筆 SQL 連同呼叫來源都記下來。長期維運的站建議把整套 debug 機制只開在 Staging 環境，正式站只在出事時短暫打開，事後立刻關掉並刪掉 debug.log，避免堆積過大或洩露路徑。

常見衝突的長相要認得出來

跑完流程之後，下次再遇到類似症狀，光看現場就能略猜根因，省下走一遍全流程的時間。幾種高頻衝突類型各自有典型的指紋，記住特徵會讓判讀快很多。

最常見的是函式名稱（Function Name）撞名。兩支外掛各自宣告了同名的全域函式，WordPress 載入較晚那支時直接致命，debug.log 會寫 Cannot redeclare function。這類錯誤訊息精確指出兩個檔案的路徑，幾乎不用猜，把較舊或較少用的那支換掉即可。

另一個高頻情境是 hook 順序衝突。兩支外掛都掛在同一個 action 或 filter 上，後執行的把先執行的結果蓋掉，常見於 SEO 外掛跟快取外掛同時動 wp_head 的 meta 輸出，或兩支表單外掛搶 wp_enqueue_scripts 的 jQuery 版本。這類衝突未必致命，卻會讓功能失效或前台 JavaScript 報錯，靠 Query Monitor 看 hook 列表最快。

少見、破壞力卻最大的是資料庫資料表互相覆蓋。兩支外掛都自建一張同名 wp_xxx 資料表，或都去寫 wp_options 同一個 key，安裝時就會互相干擾。這類問題在啟用較晚那支的當下就會出狀況，回退方式是進 phpMyAdmin 看資料表時間戳，把後建的那張先停用外掛再清掉。

排查工具怎麼挑

市面上協助排查衝突的工具不少，功能各有偏重。下面這張表把 4 款 2026 年最常用的攤開比，按站台規模與使用情境挑一款裝起來，平時不用啟用，出事時直接派上用場。

裝工具的順序建議是 Query Monitor 先上，它涵蓋的場景最廣，平時也能拿來看效能瓶頸。準備升 PHP 版本時再加 Plugin Compatibility Checker 跑一輪靜態掃描。若站務人員不熟悉 FTP 與 phpMyAdmin，可以多裝 Plugin Detective 留著當保險，在後台還進得去的前提下用精靈一鍵跑完二分法。

工具是輔助，真正能讓 wordpress 外掛衝突排查跑得順的，還是流程感——遇到白畫面先讓錯誤現形，再用二分法縮範圍，最後翻日誌對照堆疊。把這套流程練到反射動作，下次出事不用慌，半小時內就能把站救回來。