外掛剛更新完，重新整理一次網站，首頁忽然只剩下一片空白，什麼字都沒有；點進後台登入頁，同樣叫不出畫面，連輸入帳號密碼的欄位都看不到。多數人遇到這種畫面，第一反應是慌，以為網站中毒或被入侵，於是開始亂試：砍掉主題重灌、把外掛整批刪光，或是直接寫信找主機商求救。這樣亂猜亂試，往往把原本只是外掛衝突的小問題，拖成半天都還原不了的大麻煩。
這種畫面有個專有名稱，叫「白畫面」（White Screen of Death）。其實 WordPress 外掛衝突排查有一套固定順序：先停用全部外掛，打開除錯模式讓錯誤現形，再逐一啟用外掛揪出兇手，連後台都進不去時還有安全模式可以救援。照著這套順序走，多半半小時內就能定位問題，不必賭運氣亂試。
先從白畫面跟其他常見錯誤有什麼不一樣講起，再一步一步往下拆。
WordPress 外掛衝突的白畫面，跟其他錯誤有什麼不一樣？
「資料庫連線發生錯誤」「這個頁面無法正常運作，出現伺服器錯誤 500」，多數常見的 WordPress 錯誤好歹還會留一行提示字，讓你知道大概是哪個環節出錯。白畫面不一樣，畫面就是空的，沒有任何文字說明。這不是系統故障沒處理好，而是 WordPress 刻意的設計，PHP 執行到某支程式碼中止時，錯誤訊息預設不會顯示給訪客看，因為錯誤內容常常包含伺服器檔案路徑、資料庫結構這類資訊，直接攤在畫面上等於把系統內部細節攤給任何看得到這個網址的人看，是不小的資安風險。
也因為看不到任何線索，白畫面才特別讓人手足無措，只能靠「哪裡還進得去、哪裡進不去」這個線索，自己一步步縮小範圍。實際上白畫面不只一種樣子，依照卡住的位置可以分成三種情況。第一種只有前台空白，後台登入頁還打得開，通常代表問題出在某支只在前台載入的外掛或版型功能；第二種正好相反，後台登入不了，前台卻還看得到內容，問題方向多半指向後台專用的功能或某個管理介面外掛；第三種最麻煩，前後台一起當機，連登入頁的畫面都叫不出來。這三種情況修法路徑不太一樣，得先確認自己屬於哪一種，才知道接下來該往哪個方向查。
外掛更新後，網站為什麼會忽然變成一片空白？
知道自己卡在哪一種畫面之後，下一步是弄清楚背後的原因。外掛衝突造成的白畫面，通常不是網站中毒或被入侵，而是程式碼彼此打架，而且多半就發生在外掛更新前後的那一瞬間。衝突背後通常是以下幾種情況之一：
- 函式重複定義：兩支外掛剛好各自定義了同一個函式名稱，WordPress 載入到第二個時直接卡死，這在 PHP 裡稱為函式重複宣告（function redeclare），是外掛衝突最常見的成因。
- 版本不相容：外掛用到的函式，跟目前的 WordPress 核心或 PHP 版本兜不起來，執行到一半呼叫到一個根本不存在的函式，程式當場中止。
- 記憶體耗盡：某支外掛特別耗資源，把伺服器分配給 PHP 的記憶體用光，跟前面兩種程式碼寫錯的情況不同，這是資源不夠用的問題。
- 更新中斷、檔案不完整：外掛更新到一半遇到網路斷線或逾時，部分檔案沒下載完整，殘缺的程式碼一樣會讓 WordPress 讀不下去。
這四種成因看起來各不相同，但都指向同一件事，就是問題能被具體定位出來，不是無解的黑箱。接下來要做的，就是一步步把可能性收斂到其中一個，而不是憑感覺亂猜。
後台信箱裡，有沒有「網站發生技術問題」的通知信？
把可能性一步步收斂之前，還有一個地方值得先看一眼，免得繞遠路，那就是管理員的電子信箱。WordPress 從 5.2 版開始，內建了一套致命錯誤保護機制，遇到某支外掛或佈景主題導致程式當機時，不一定會直接丟出一片空白，訪客看到的可能是一句「網站發生技術問題」之類的提示，同時系統會自動寄一封信到你註冊的管理員信箱。
這封信裡有一組專屬連結，點進去能以「救援模式」（Recovery Mode）登入後台。這個模式會把造成問題的外掛或佈景主題，暫時只對你這個登入的瀏覽器停用，其他訪客看到的前台畫面不受影響。登入後，後台會直接標出是哪個外掛或佈景主題出錯，你可以當場把它停用，問題排除後再退出救援模式。整個過程不用碰 FTP，也不會動到任何原始檔案。
排查白畫面的第一步，建議先查一次這封信有沒有收到。收到了，直接照信裡的連結走通常最快；沒收到，或是打開網站看到的真的是完全空白、什麼提示字都沒有，才是接下來要處理的真正白畫面，得走手動排查的路線。
排查第一步：停用全部外掛，確認問題是不是外掛引起的
如果你還進得去後台，WordPress 外掛衝突排查的第一步，永遠是同一件事，就是先把所有外掛通通停用，看看網站會不會恢復正常。
動手之前，先把目前有哪些外掛是啟用狀態記下來，或乾脆備份一次網站檔案與資料庫。停用外掛只是暫時關閉功能，不會刪除任何設定資料，可以放心操作，但先留一份清單，之後才知道該照原樣一個一個開回來。
到後台「外掛」>「已安裝外掛」，把所有外掛整批打勾選起來，選單裡的「大量操作」選「停用」，一次全部關掉。停用完，前台跟後台都重新整理一次，兩邊都要測。
接下來看結果會往哪個方向走。停用全部外掛之後，如果網站恢復正常，問題幾乎可以確定出在外掛身上，可以直接跳到後面逐一重新啟用外掛的步驟。如果停用之後畫面依然空白，代表外掛不是唯一的原因，得往下開啟除錯模式，先把藏在背後的錯誤訊息挖出來看（佈景主題或記憶體不足的可能性，留到後面再處理）。
排查第二步：打開 WP_DEBUG，讓藏起來的錯誤訊息現形
如果停用全部外掛後畫面還是空白，或者你想更精準地知道問題出在哪一行程式碼，下一步是打開 WordPress 內建的除錯模式，讓原本被藏起來的錯誤訊息現形。
用 FTP 用戶端或主機控制台內建的檔案管理員，連進網站根目錄，找到 wp-config.php 這支檔案。動手改之前，先下載一份備份放在自己電腦裡，萬一改壞了還能救回來。
找到檔案裡 /* That's all, stop editing! */ 這一行，在它前面加入以下三行：
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Code language: PHP (php)WP_DEBUG 是除錯模式的總開關；WP_DEBUG_LOG 讓錯誤訊息寫進 wp-content/debug.log 這支記錄檔；WP_DEBUG_DISPLAY 設成 false，代表不要把錯誤訊息直接顯示在前台頁面上讓所有訪客都看到，只留在檔案裡自己查，這也跟前面提到的資安考量互相呼應。
存檔上傳，回到瀏覽器重新整理一次原本白畫面那一頁，讓錯誤重新觸發一次，接著回頭到 wp-content/debug.log 這支檔案，用文字編輯器打開來看，裡面會記錄剛剛觸發的完整錯誤訊息。查完之後，務必把這三行改回 false，或是整段移除；除錯模式留在正式站上，等於把系統內部細節長期曝光在外，是不必要的風險。
debug.log 打開後，最常見到這三種錯誤提示
debug.log 打開後，裡面常常是一長串英文加檔案路徑，第一次看很容易眼花，但真正常見的錯誤類型其實不多，大概逃不出下面這三種：
- Cannot redeclare function：代表有兩支外掛剛好定義了同一個函式名稱，WordPress 讀到第二個定義時直接中止。錯誤訊息裡點名的那個檔案，通常就是衝突對象所在的外掛。
- Call to undefined function：程式呼叫了一個根本不存在的函式，最常見的原因是外掛用到的函式，跟目前的 PHP 或 WordPress 版本已經對不上。
- Allowed memory size of X bytes exhausted：代表伺服器分配給 PHP 的記憶體被用光了，這是資源不足的問題，不是程式碼寫錯，對應的排查方式留到後面記憶體那一段。
不管是哪一種，錯誤訊息裡的檔案路徑跟行號才是抓兇手最直接的線索。只要路徑裡看到 wp-content/plugins/ 後面接著某支外掛的資料夾名稱，就等於已經找到問題出在哪一支外掛。
錯誤訊息看不懂，可以怎麼用 AI 幫忙讀？
debug.log 裡的錯誤訊息常常一長串英文加檔案路徑跟 stack trace，對沒有工程背景的站長來說不好消化。這裡有個現成的小技巧，把整段錯誤訊息複製起來，貼給 ChatGPT、Claude 這類 AI 助手，請它用中文解釋這代表什麼問題、大概是哪一支外掛造成的、下一步該怎麼做。
這類制式的 PHP 錯誤訊息有固定格式，AI 助手對這種格式的判讀相當準確，能省下自己一行一行爬文比對的時間。要注意的是，貼錯誤訊息本身不會洩漏敏感資料，但不要順手把資料庫帳號密碼、API 金鑰這類其他機密內容一起貼上去；而且 AI 給的建議終究只是參考，回到自己的網站上還是要實際驗證過，不要沒弄懂就直接改動核心程式檔案。
排查第三步：逐一啟用外掛，找出真正衝突的那一個
延續前面全部停用的狀態，接下來換成一個一個重新啟用外掛，每開一個就重新整理一次前台跟後台，確認畫面正常。哪一支外掛一啟用，白畫面就跟著回來，兇手就是它。
優先測最近安裝或最近更新過的外掛，命中的機率通常比較高，能省下不少時間；外掛數量多的話，建議順手記一下測到第幾支，免得中途被其他事打斷，回來還要從頭猜一次。
找到兇手之後，先把它停用，讓網站恢復正常運作，再往下看有哪些解法可以選。
免手動逐一開關，WordPress.org 有現成免費外掛代勞
如果覺得一個一個手動停用、啟用太花時間，WordPress.org 官方外掛目錄裡有一支免費外掛可以代勞，叫做 Health Check & Troubleshooting。它的疑難排解模式能在不影響一般訪客瀏覽的前提下，只讓你自己看到全部外掛停用、切換成預設佈景主題之後的畫面，再從這個介面裡逐一切換外掛的開關，等於把前面手動的步驟包成一個現成介面。好處是只有登入的你自己看得到暫停外掛後的樣子，其他訪客照常看到原本的網站，不會被你的測試過程打擾。這支外掛適合已經能登入後台、想省幾個手動步驟的人，不是排查白畫面的必要工具，前面的手動做法一樣完全可行。
連後台都進不去，怎麼用 FTP 做安全模式救援？
前面幾種做法有個共同前提，後台登入頁至少叫得出來。如果連登入頁都是一片空白，前面「後台大量停用」「打開除錯模式」這些都做不了，因為根本進不去後台介面，這時候就得換一個角度，直接連到網站的檔案系統動手，不透過 WordPress 後台。
做法是用 FTP 用戶端（常見的有 FileZilla）或主機控制台內建的檔案總管，連進網站根目錄。這個層級不需要登入 WordPress，只要有主機的 FTP 帳號密碼或控制台登入權限就能操作。
用 FTP 或檔案總管，強制停用全部外掛
連進網站根目錄之後，找到 wp-content 這個資料夾，裡面有一個叫 plugins 的子資料夾，存放所有外掛的程式檔案。把整個 plugins 資料夾改名，改成 plugins_disabled 或任何自己看得懂的名字都可以。WordPress 判斷外掛有沒有啟用，是靠掃描 plugins 這個資料夾，資料夾一旦被改名找不到，原本啟用的所有外掛就會被自動視為未啟用，等同於在後台按了一次「全部停用」。改完名稱，重新整理前台，看看畫面有沒有恢復正常。
改回外掛資料夾名稱，逐一定位問題外掛
如果前台真的恢復正常，代表判斷是對的，問題出在外掛身上。接下來把 plugins_disabled 改名回 plugins，這時候全部外掛會回到未啟用狀態，但外掛原本的設定資料不會遺失。然後進到 plugins 資料夾底下，這次只挑一支外掛的子資料夾改名，其餘外掛的資料夾名稱維持不動，等同單獨啟用了這一支，重新整理測試一次。一支一支輪流測下去，哪一支改名之後白畫面又跑出來，那支就是兇手。找到之後，把這支外掛的資料夾名稱維持在改過的狀態，等於保持停用，其餘外掛的資料夾名稱全部改回正常，網站就能恢復運作。
找到問題外掛後，接下來有哪幾種解法？
抓到兇手之後，接下來的處理方式，依照情況大概分成以下幾種：
- 先檢查外掛有沒有更新可用：不少衝突的根源，只是外掛版本太舊，沒跟上 WordPress 核心或 PHP 的更新腳步。更新到最新版，往往就能解決問題，是成本最低、優先該試的做法。
- 找功能相近的替代外掛：如果外掛作者已經很久沒更新，或這次衝突短期內看不出修好的跡象，可以到 WordPress 外掛目錄找一支功能類似的替代品，先撐過去。
- 保持停用，先讓網站恢復運作：如果這支外掛不是核心功能，一時找不到替代品也沒關係，先讓它維持停用狀態，之後有時間再回頭處理，網站正常運作比什麼都優先。
- 看得懂程式碼，可以直接對照行號排除：debug.log 裡的檔案路徑跟行號，可以直接對照外掛的原始程式碼，找到重複定義的函式名稱或衝突的那一行，手動排除。這個做法風險比較高，動手前一定要先備份，改壞了至少能救回來。
- 持續無解，找開發者或工程師協助：如果以上都試過還是卡住，或者牽涉的層面已經超出外掛本身，聯絡外掛開發者，或找專門處理 WordPress 的工程師接手，會比自己繼續摸索更有效率。
照著流程排查完，還是白畫面，代表什麼？
前面的排查順序，幾乎能抓出絕大多數因外掛引起的白畫面。但如果全部外掛都排除過一輪，問題依然存在，代表答案不在外掛身上，得往幾個常被忽略的方向去找。
會不會是 PHP 記憶體不夠用？
如果前面 debug.log 裡看到的是 Allowed memory size of X bytes exhausted 這行，代表卡住的原因是記憶體不夠用，不是外掛程式碼本身寫錯。解法是回到 wp-config.php，一樣在 /* That's all, stop editing! */ 這行之前，加入以下這一行，把 WordPress 允許使用的記憶體上限拉高：
define( 'WP_MEMORY_LIMIT', '256M' );Code language: PHP (php)存檔後重新整理測試。如果調高之後問題依然存在，代表主機端的 PHP 設定可能蓋過了這個數值，這時候就得直接聯絡主機商，請對方從伺服器端調高 PHP 的記憶體限制。
佈景主題，會不會才是問題所在？
外掛都排除了，問題依然在，下一個該懷疑的對象是佈景主題。如果還進得去後台，到「外觀」>「佈景主題」，切換成 WordPress 內建的預設佈景主題，例如 Twenty Twenty-Four。如果連後台都進不去，做法跟外掛一樣，用 FTP 連進 wp-content/themes，把目前使用中的佈景主題資料夾改名，WordPress 找不到原本的佈景主題，就會自動切回內建的預設佈景主題。
切換之後如果網站恢復正常，問題就出在佈景主題身上，很可能是佈景主題裡客製化過的 functions.php 出現語法錯誤。這時候該做的是檢查最近有沒有改過主題裡的檔案，或是聯絡佈景主題的開發者確認。
更新到一半中斷，會不會殘留了 .maintenance 檔案？
還有一種比較少人知道的情況。WordPress 在進行核心或外掛更新的過程中，會在網站根目錄暫時建立一個叫 .maintenance 的檔案，標示網站正在維護中。正常情況下更新完成後這個檔案會自動被刪除，但如果更新途中網路斷線或連線逾時，這個檔案有機率沒被清乾淨，殘留下來讓網站卡在維護中的畫面，或是直接顯示空白。
排除方法是用 FTP 連到網站根目錄，跟 wp-config.php 同一層，找 .maintenance 這個檔案。找到的話直接刪除，重新整理測試。刪完之後記得回後台確認一次，剛剛那次沒完成的 WordPress 或外掛更新，版本是不是真的有更新成功，免得留下一半新一半舊的狀態。
常見排查方法都試過了，還是空白，該找誰？
如果連記憶體、佈景主題、.maintenance 檔案都排除過，畫面還是空白，先別急著責怪自己操作有問題，單純是這次的狀況比較深層，不是照著步驟就一定能自己修好的類型。
這時候最有效的做法，是把 debug.log 裡完整的錯誤訊息，連同前面已經試過哪些方法，整理成一段文字。不管接下來要找的是外掛開發者、佈景主題開發者，還是專門處理 WordPress 的工程師，對方拿到這份完整紀錄，都能省下重新從頭排查的時間，更快接手。也可以直接聯絡主機商，請對方從伺服器端的 PHP 或資料庫錯誤紀錄，確認問題是不是出在主機層級。
怎麼讓外掛衝突不要再發生第二次？
排查完一次白畫面，大概沒有人想再經歷第二次。以下幾個習慣，能大幅降低外掛衝突再發生的機率：
- 先在暫存網站測過，再套用到正式站：更新外掛、佈景主題或 WordPress 核心之前，先在暫存網站（staging site）跑一次，確認沒問題再套用到正式站。多數主機服務商都有一鍵建立暫存網站的功能，直接用現成的就好，不必自己另外架一套。
- 裝新外掛前，先看更新頻率跟版本相容標示：WordPress 外掛頁面上會標示相容至哪個 WordPress 版本，跟最後更新時間，太久沒更新的外掛，跟目前版本兜不起來的風險比較高，裝之前先看一眼這兩項資訊。
- 定期清掉不再使用的外掛：停用不等於刪除，長期沒在用的外掛留在後台只是徒增衝突的機會，建議定期盤點，真的用不到就直接刪掉，別放著閒置佔資源。
- 任何更新之前，先備份檔案跟資料庫：備份是排查失敗時的最後一道防線，就算前面的步驟都沒能解決問題，至少還能還原到更新之前的正常狀態。
整套 WordPress 外掛衝突排查邏輯，其實就是不斷縮小範圍，先排除外掛，再排除佈景主題，最後排除環境限制，一步一步把不知道哪裡壞，變成抓到具體是哪裡壞。排查前的備份，跟排查過程裡的耐心，比任何一個單一步驟都重要。沒有備份，任何嘗試都多一分風險；沒有耐心，亂猜亂試反而拖得更久。下次網站又忽然變成一片空白，你已經有一套現成的順序可以照著走，不必再慌著亂猜。