WordPress 網站一片空白？資深工程師手把手教你啟用錯誤日誌 (Error Log)，秒速揪出問題元兇！
嗨，我是浪花科技的資深工程師 Eric。寫了這麼多年的程式，看過各種千奇百怪的網站問題，但最讓新手甚至老手都頭痛的，莫過於那傳說中的「死亡白畫面」（White Screen of Death, WSOD）。前一秒網站還好好的，更新個外掛或主題，下一秒就只剩下一片刺眼的白，後台也進不去，簡直是網站管理員的終極惡夢。
這時候，你可能會像無頭蒼蠅一樣，開始亂停用外掛、切換主題，但這都只是在瞎猜。身為一個專業的工程師，我們不搞通靈，我們講求證據。而找出 WordPress 問題元兇的最有力證據，就藏在一個你可能從未啟用過的功能裡——那就是 WordPress 錯誤日誌（Error Log）。
今天這篇文章，我就要以一個老工程師的囉嗦精神，帶你從頭到尾徹底搞懂 WordPress 的除錯模式與錯誤日誌，讓你從此告別瞎猜，精準、快速地解決網站問題。
什麼是 WordPress 錯誤日誌 (Error Log)？為什麼它這麼重要？
簡單來說，WordPress 錯誤日誌就是一個文字檔，專門用來記錄網站運行過程中發生的所有 PHP 錯誤、警告和通知。你可以把它想像成是飛機的「黑盒子」，當網站「墜毀」（掛掉）時，這個黑盒子裡就記錄了所有關鍵的線索。
很多時候，網站出錯並不會直接顯示在前端。你可能只會看到一個破碎的排版、一個無法使用的功能，或就是那片令人絕望的白畫面。但在此同時，伺服器後端可能已經 screaming with errors。錯誤日誌就是捕捉這些「尖叫聲」的工具。
一個典型的錯誤訊息會告訴你三件最重要的事：
- 錯誤類型： 是致命錯誤（Fatal Error）導致網站直接崩潰，還是一個警告（Warning）或通知（Notice）？
- 錯誤描述： 到底發生了什麼事？是找不到函式、記憶體不足，還是語法寫錯了？
- 錯誤地點： 這是最有價值的資訊！它會精準地告訴你是哪個檔案的第幾行程式碼出了問題。
有了這些資訊，除錯就從大海撈針變成了按圖索驥。這也是為什麼，當客戶的網站出問題時，我第一件事通常不是問「你做了什麼？」，而是「可以讓我看看 Error Log 嗎？」。這才是工程師的溝通方式嘛！
為什麼我的 WordPress 找不到 Error Log？
這是一個非常常見的問題：「Eric，你說的 Error Log 我怎麼都找不到？」
答案很簡單：因為在正式上線的網站環境中，WordPress 預設是關閉除錯模式和錯誤日誌的。
這不是 Bug，而是一個重要的安全機制。試想一下，如果任何訪客都能在你的網站上看到詳細的錯誤訊息，這不就等於把伺服器路徑、程式碼邏輯等敏感資訊暴露給有心人士了嗎？這會造成嚴重的安全漏洞。此外，不斷寫入日誌也會對網站效能產生輕微的影響，這也是為什麼我們在優化網站速度時，會確保這些功能在平時是關閉的。
所以，找不到日誌是正常的。接下來，我們就要學習如何在需要的時候，安全地把它打開。
手把手教學：如何安全啟用 WordPress 除錯模式與錯誤日誌
啟用這個功能的關鍵，在於編輯 WordPress 的核心設定檔：wp-config.php。這個檔案非常重要，可以說是整個網站的大腦，所以在動手之前，我得囉嗦兩句：
⚠️ 操作前警告： 修改 wp-config.php 有風險。一個小小的語法錯誤（例如少了一個分號）都可能導致你的網站直接掛掉。在編輯前，務必、務必、務必備份這個檔案！
步驟一：找到並備份 wp-config.php
你需要透過 FTP 工具（如 FileZilla）或主機的檔案管理器，連線到你的網站伺服器。wp-config.php 這個檔案通常位於你 WordPress 安裝的根目錄下，跟 wp-content、wp-admin 這些資料夾在同一層。
找到後，先下載一份到你的電腦上，這就是你的備份。如果改壞了，把這個備份檔傳回去覆蓋就好。
步驟二：加入除錯模式的「三劍客」
用純文字編輯器（例如 VS Code, Sublime Text，千萬別用 Word）打開 wp-config.php。往下拉，你會找到一行註解寫著：
/* That's all, stop editing! Happy publishing. */我們要做的，就是在這行註解的上方，加入以下幾行程式碼。這是我稱之為「除錯三劍客」的黃金組合：
// 開啟除錯模式
define( 'WP_DEBUG', true );
// 將錯誤寫入日誌檔案，而不是顯示在畫面上
define( 'WP_DEBUG_LOG', true );
// 不在網站前端顯示錯誤訊息（非常重要！）
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
讓我這個老工程師來解釋一下這幾行咒語的意義：
define( 'WP_DEBUG', true );：這是總開關，告訴 WordPress：「嘿，我們現在要進入除錯模式了！」define( 'WP_DEBUG_LOG', true );：這是關鍵的一行。它告訴 WordPress 把偵測到的所有錯誤，都記錄到一個名為debug.log的檔案裡。define( 'WP_DEBUG_DISPLAY', false );：這是保護你網站的生命線！它確保錯誤訊息不會直接顯示在網站的前端給所有人看。如果你把它設為true，那跟裸奔沒兩樣，非常危險。下面的@ini_set則是更強制地關閉 PHP 的錯誤顯示功能，雙重保險。
把這段程式碼貼上後，儲存並上傳回你的伺服器，覆蓋掉原本的 wp-config.php。
步驟三：重現問題並找到 debug.log
設定完成後，回到你的網站，重新操作一次會引發問題的步驟（例如，重新整理那個白畫面的頁面）。這個動作會觸發錯誤，並讓 WordPress 將錯誤訊息寫入日誌。
接著，回到你的 FTP 或檔案管理器，查看 /wp-content/ 這個資料夾。如果一切順利，你應該會看到一個新產生的檔案，叫做 debug.log。
把它下載下來，用文字編輯器打開，裡面就是你破案的關鍵線索！
如何看懂錯誤日誌？資深工程師的解讀心法
打開 debug.log，你可能會看到像這樣的內容：
[10-Oct-2023 08:30:15 UTC] PHP Fatal error: Uncaught Error: Call to undefined function non_existent_function() in /home/user/public_html/wp-content/plugins/my-buggy-plugin/includes/functions.php:123
Stack trace:
#0 /home/user/public_html/wp-content/plugins/my-buggy-plugin/my-buggy-plugin.php(45): include_once()
#1 /home/user/public_html/wp-settings.php(409): include_once('/home/user/publ...')
#2 /home/user/public_html/wp-config.php(90): require_once('/home/user/publ...')
#3 /home/user/public_html/wp-load.php(50): require_once('/home/user/publ...')
#4 /home/user/public_html/wp-blog-header.php(13): require_once('/home/user/publ...')
#5 /home/user/public_html/index.php(17): require('/home/user/publ...')
#6 {main}
thrown in /home/user/public_html/wp-content/plugins/my-buggy-plugin/includes/functions.php on line 123看起來很嚇人對吧？別怕，我們只需要關注幾個重點：
- 錯誤類型：
PHP Fatal error。看到 “Fatal” 就知道事情大條了，這通常就是造成死亡白畫面的元兇。 - 錯誤描述：
Call to undefined function non_existent_function()。意思是程式碼嘗試呼叫一個不存在的函式。 - 錯誤地點：
in /home/user/public_html/wp-content/plugins/my-buggy-plugin/includes/functions.php on line 123。這就是金礦！它清楚地告訴你，問題出在一個名為 `my-buggy-plugin` 的外掛，具體檔案是 `functions.php` 的第 123 行。
有了這些資訊，解決方案就非常明確了：
- 你可以先透過 FTP 暫時將
/wp-content/plugins/my-buggy-plugin/這個資料夾改名，這樣就能強制停用此外掛，讓網站先恢復運作。 - 接著，你可以聯絡此外掛的作者，把這段錯誤訊息提供給他們，請他們修復。
- 如果你懂程式，也可以自己去看看第 123 行到底寫了什麼鬼，或許只是個簡單的拼字錯誤。這也是深入了解 WordPress Hooks 運作原理的好機會。
工程師的囉嗦提醒與進階技巧
1. 用完記得關掉！
這是最重要的提醒！當你解決問題後，一定要回到 wp-config.php 檔案，將 WP_DEBUG 的值改回 false，或者直接刪掉你剛才加入的那幾行程式碼。
define( 'WP_DEBUG', false );一直開著除錯模式，不僅有安全風險，debug.log 檔案也可能會長到非常大，佔用你的主機空間。
2. 專業的做法：在預備環境 (Staging) 除錯
對於重要的商業網站，直接在正式站上開關除錯模式還是有風險的。最專業的做法是建立一個「預備環境」（Staging Site），這是正式站的完整複製版。你在預備環境中啟用除錯、測試更新、解決問題，確認一切都完美後，再將變更同步到正式站。這就像是 F1 賽車的模擬器，讓你可以在不影響正式比賽的情況下進行各種調校。這也是我們在進行像是WP-Cron這類底層功能排錯時的標準流程。
3. 日誌檔沒出現怎麼辦？
有時候即使設定正確，debug.log 還是沒出現。這通常是「權限」問題。WordPress 需要有權限在 wp-content 資料夾中寫入檔案。請檢查 wp-content 的資料夾權限，通常設定為 755 即可。
結論：讓錯誤日誌成為你的超能力
面對 WordPress 的各種疑難雜症，恐慌和猜測是最大的敵人。學會使用 WP_DEBUG 和錯誤日誌，就像是給自己配備了 X 光眼鏡，能夠直接看穿問題的本質。
記住這個流程：備份 -> 開啟除錯 -> 重現問題 -> 查看日誌 -> 解決問題 -> 關閉除錯。養成這個好習慣，你處理 WordPress 問題的能力將會提升好幾個檔次。
延伸閱讀
- 你的 WordPress 排程又失蹤了？資深工程師教你搞定 WP-Cron，從此告別「錯過排程」惡夢！
- WordPress 開發的任督二脈：搞懂 Action & Filter Hooks，客製化功力大爆發！
- 網站慢到像烏龜？解鎖 WordPress Cache 的黑魔法，讓你的網站速度一飛沖天！
需要更專業的協助嗎？
當然，有些問題可能牽涉到更深層的伺服器設定或複雜的程式碼衝突。如果你嘗試了以上方法仍然束手無策，或者根本不想自己動手弄髒手，浪花科技的團隊隨時準備好為你提供專業的技術支援。我們處理過各種棘手的 WordPress 狀況，能快速為你診斷並修復問題。
立即聯繫我們，讓專業的來，把你的時間花在更重要的事情上！
