WordPress 白屏死機（White Screen of Death）完整解析

白屏死機是一種你看不見的 PHP 嚴重錯誤。WordPress 在渲染途中遇到無法復原的錯誤，PHP 停止執行，而由於正式環境的伺服器關閉了錯誤顯示，頁面回傳的是一片空白，而不是印出原因。修復幾乎從來不需要靠猜：開啟除錯記錄檔、打開 wp-content/debug.log、讀最後一行 fatal 錯誤。它會指名出確切的檔案 —— 幾乎一定是某個外掛或佈景主題 —— 而那一行就是整個修復的答案。

為什麼畫面是空白的

PHP 有一個叫做 display_errors 的設定。在開發用的機器上通常是開啟的，所以發生嚴重錯誤時會把堆疊追蹤印在畫面上。在正式的主機上則預設關閉，因為把檔案路徑和錯誤洩漏給訪客是個資安問題。所以當某個東西丟出嚴重錯誤 —— 呼叫一個已經不存在的函式、某個沒有載入的類別、外掛更新裡的語法錯誤 —— PHP 就會終止，而且什麼都不送出。你的瀏覽器渲染出一份空白文件。這就是「白屏」。

自 WordPress 5.2 起有一個嚴重錯誤處理器（WP_Fatal_Error_Handler）會試著攔截這些錯誤。當它運作正常時，你不會看到空白頁 —— 你會看到「這個網站發生嚴重錯誤。」，外加一封寄到管理員信箱的郵件，裡面通常包含實際的錯誤內容以及一個進入復原模式（Recovery Mode）的連結。真正空白的畫面，通常表示錯誤在該處理器來得及執行之前就觸發了：例如剖析／語法錯誤（在編譯時期就被攔下）、損壞的 must-use 外掛，或是使用中佈景主題的 functions.php 裡的嚴重錯誤。無論是哪種，原因都被寫在某個地方了。你只是得把「寫下來」這件事打開而已。

依序修復

1. 開啟記錄檔。 透過 SFTP 編輯 wp-config.php，在 /* That's all, stop editing! */ 這一行的上方加入這段：

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

WP_DEBUG_DISPLAY 設為 false 可以讓錯誤不出現在公開頁面上，同時 WP_DEBUG_LOG 會把錯誤寫進 wp-content/debug.log。重新載入一次故障的頁面，產生一筆新的紀錄。

2. 讀最後一行 fatal 錯誤。 打開 wp-content/debug.log，看最底下：

tail -n 30 wp-content/debug.log

你要找的是像這樣的一行：

[14-Jul-2026 09:12:44 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product() in /var/www/html/wp-content/plugins/some-addon/includes/class-widget.php:88

路徑就指名了罪魁禍首：plugins/some-addon。那就是你的答案。如果追蹤很長，或訊息很難懂（Allowed memory size exhausted、Cannot redeclare、某個你不認得的類別名稱），把它貼進我們的錯誤記錄檔解碼器 —— 它會過濾掉雜訊，告訴你路徑指向哪個外掛或佈景主題，並解釋該特定錯誤類型代表什麼意思。

3. 停用被指名的元件。 你進不去 /wp-admin，所以要透過 SFTP 來做。把出問題的外掛資料夾改名，例如 some-addon → some-addon.off。WordPress 無法載入一個找不到的資料夾，於是它會停用該外掛，網站也就恢復了。如果記錄檔指向的是你的佈景主題，就把使用中的佈景主題資料夾改名來切換成預設佈景主題 —— WordPress 會退回到內建的 twentytwentysomething。

4. 如果記錄檔寫不出來， 那就是 wp-content 不可寫入，或錯誤發生在伺服器層級。改去查主機的 PHP 錯誤記錄檔：

find . -name "error_log" -newermt "-1 hour"

一樣的資訊，不同的檔案。cPanel／Apache 環境常會在網站根目錄或出錯的目錄裡丟一個 error_log。

不該做的事

別只是把記憶體上限調高。 網路上被轉貼最多的建議，就是把 WP_MEMORY_LIMIT 提高到 256M 或 512M。只有在記錄檔確實寫著 Allowed memory size of N bytes exhausted 時，這才能修好白屏死機。如果錯誤是 Call to undefined function，加記憶體毫無用處 —— 你只是隨便改了一個設定，畫面還是白的。先讀記錄檔，確認記憶體才是問題後，再去調高記憶體。

別清了快取就當作已經診斷完畢。 白屏是 PHP 在伺服器上、在任何 HTML 存在之前就終止了。一個過期的快取資源不可能造成空白文件。（一個損壞的快取外掛可以 —— 但記錄檔會指名它，這正是重點所在。）

別去編輯或重裝 WordPress 核心。 嚴重錯誤幾乎從來不在 wp-includes 或 wp-admin；它在記錄檔指向的那個外掛或佈景主題裡。重裝核心又慢又有風險，而且是在處理一個你根本還沒確認的表面症狀。

別把所有外掛停用再一個一個盲目重新啟用。 二分法有效，但那是慢路徑。記錄檔一步就告訴你確切的資料夾。只有在完全沒有任何可讀的錯誤時，才動用「全部關掉」的方法。

別在正式環境讓 display_errors 保持開啟。 網站恢復後，移除那些除錯用的 define（或把 WP_DEBUG 設回 false）。印給訪客看的錯誤會洩漏你的路徑。

還是卡住了？

如果記錄檔指名了某個外掛，但停用它並沒有清掉白屏，那就是第一個錯誤底下還有第二個嚴重錯誤 —— 把記錄檔重新打開，讀新的最後一行；fatal 錯誤是會層層堆疊的。如果訊息本身就是那道牆，把它丟進錯誤記錄檔解碼器，讓它幫你翻譯錯誤類型和檔案路徑。白屏只有在記錄檔關著的時候才會一直是個謎。