wp-config.php 設定教學:調記憶體限制、開偵錯模式

wp-config.php 是每個 WordPress 安裝都有的設定檔,放在網站根目錄,裡面除了資料庫連線資訊,還藏了幾十個「進階常數」——但預設值不一定適合你的網站。三個最常被問到、也最常被忽略的場景:文章編輯久了資料庫塞滿修訂版本(revision)、換主題或裝外掛後動不動跳「Allowed memory size exhausted」記憶體不足錯誤、外掛出問題卻只看到一片空白畫面完全不知道錯在哪。這三個問題都不需要裝外掛,直接在 wp-config.php 加幾行 define() 就能解決,而且改完立即生效、不影響資料庫既有資料。本文示範的常數與寫法對齊 WordPress 官方開發文件(2026-01-07 更新版本),照著改就是官方支援的標準做法。

🛠️ 實戰步驟

⚠️ 改檔前一定要做:先用 FTP 把現有的 wp-config.php 下載一份存到自己電腦(檔名可改成 wp-config-backup.php 避免搞混),改壞了直接把備份傳回去覆蓋就能復原。這個檔案控制整個網站能不能連上資料庫,改錯一個字元、少一個分號都可能讓網站直接白畫面。

步驟一:限制修訂版本數量(WP_POST_REVISIONS)

WordPress 預設會幫每篇文章、頁面保留「所有」編輯歷程的修訂版本,寫作時間越久、改越多次,資料庫裡的 wp_posts 資料表就會累積越多筆用不到的舊版本,拖慢資料庫查詢效能。用文字編輯器打開 wp-config.php,找到 /* That's all, stop editing! */ 這一行(或類似的「停止編輯」註解),在它上方加入:

define( 'WP_POST_REVISIONS', 5 );

這行的意思是「每篇文章最多保留 5 個修訂版本,超過的舊版本自動不再累積」。如果想完全關閉修訂功能,把數字換成 false;如果不設定這個常數,WordPress 預設會存下每一次的編輯紀錄(等同無限制)。既有文章已經累積的舊修訂版本不會被這行常數自動清掉,需要另外用資料庫工具清除——這部分站內已有完整教學,可參考《WordPress 資料庫優化》一文的做法。

步驟二:調高 PHP 記憶體上限(WP_MEMORY_LIMIT)

「Allowed memory size of xxxxxx bytes exhausted」是外掛/主題吃太多記憶體時最常見的錯誤畫面。WordPress 官方文件說明,系統預設只會嘗試把 PHP 記憶體拉到 40MB(單站)或 64MB(多站網路),這對裝了不少外掛的現代網站經常不夠用。在 wp-config.php 的同一個位置加入:

define( 'WP_MEMORY_LIMIT', '256M' );

如果後台管理畫面(編輯文章、更新外掛)還是常常記憶體不足,可以另外加一行,只針對後台拉更高上限:

define( 'WP_MAX_MEMORY_LIMIT', '512M' );

💡 為什麼要這樣做?這個常數只影響 WordPress 這個應用程式能用的 PHP 記憶體,不會動到主機上其他網站或服務;而且 WordPress 會自動比較這個設定值跟主機 php.ini 實際配置的上限,兩者取較低者生效——如果主機本身把 PHP 記憶體鎖在 128M,你在這裡填 256M 也沒用,得請主機商調高。數字調越大不代表網站越快,只是解決「記憶體不夠用」的錯誤,真正吃記憶體的外掛/主題還是該找出來換掉。

步驟三:安全開啟偵錯模式(WP_DEBUG)

網站出現「白畫面」或某個功能明明裝好卻不動作,最快的排查方式就是開啟偵錯模式看 PHP 到底噴了什麼錯誤。但偵錯模式不能直接開在正式營運的網站上給所有訪客看,正確做法是把錯誤訊息寫進一個訪客看不到的紀錄檔:

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

四行的分工:WP_DEBUG 是總開關,打開後才會啟用下面兩個子設定,同時把 PHP 錯誤回報等級拉到最完整(E_ALL);WP_DEBUG_LOG 讓錯誤訊息寫進 wp-content/debug.log 這個檔案;WP_DEBUG_DISPLAY 設 false 確保錯誤訊息不會直接顯示在網頁上給訪客看到;最後那行 @ini_set 是保險,避免主機 php.ini 本身設定「顯示錯誤」把 WordPress 的設定蓋過去。抓完錯之後記得把 WP_DEBUG 改回 false,並且刪掉 debug.log(這個檔案預設放在公開可存取的路徑,長期留著等於把網站的除錯資訊攤在外面給人看)。

步驟四:驗證結果

三個常數都存檔上傳後,回到 WordPress 後台隨便編輯一篇文章存成草稿,確認網站沒有跳出白畫面或錯誤訊息;接著到 wp-content/ 目錄用 FTP 確認有沒有新產生 debug.log(代表 WP_DEBUG_LOG 生效);最後如果先前有記憶體不足的錯誤,重複觸發同樣的操作(例如更新同一個外掛),確認錯誤訊息不再出現。三項都正常就代表設定成功。

🔙 萬一翻車:回退步驟

情境一:改完存檔後網站直接白畫面

九成是打錯字元(少了分號、括號沒對齊)。用 FTP 打開 wp-config.php 檢查剛剛加的那幾行,或直接用一開始備份的 wp-config-backup.php 覆蓋回去,網站會立刻恢復。

情境二:開了 WP_DEBUG 之後後台變得很難用(滿版都是警告訊息)

代表 WP_DEBUG_DISPLAY 沒設成 false,或是主機的 display_errors 沒被 @ini_set 蓋掉。檢查步驟三那四行是否照抄無誤;找不到問題就先把 WP_DEBUG 改回 false 存檔,網站會恢復正常,之後再慢慢排查。

情境三:記憶體上限調了還是跳錯誤

代表問題出在主機 php.ini 本身的上限比你設的還低,wp-config.php 這邊怎麼調都沒用,需要聯絡主機商確認 PHP 記憶體配置或考慮升級方案。

💡 總結:進階玩法與底層邏輯

這三個常數只是 wp-config.php 裡的一小部分,官方文件裡其實還列了幾十個。比較值得順手認識的兩個:DISALLOW_FILE_EDIT 設成 true 可以把後台「外觀 → 佈景主題編輯器」「外掛 → 外掛檔案編輯器」整個選單拿掉,對防止帳號被盜後被用來竄改網站檔案是很基本的一道防線;WP_CACHE 則是多數快取外掛安裝時會自動幫你加的常數,跟頁面/物件快取的機制有關,這部分站內另有專文拆解(物件快取 vs 頁面快取)。這幾個常數的共通點是:全部都只在 wp-config.php 這個檔案生效,跟後台介面上的設定完全是兩條路,這也是為什麼帳號被盜、後台登不進去時,有經驗的人第一件事是先去檢查這個檔案有沒有被動過手腳。

❓ 常見問題

Q:改了 wp-config.php 需要重新啟動網站或伺服器嗎?

不需要,這個檔案在每次有人瀏覽網站時都會被重新讀取一次,存檔上傳後立即生效,不用重啟主機或 PHP 服務。

Q:這些常數在多站網路(Multisite)也一樣適用嗎?

WP_MEMORY_LIMIT、WP_DEBUG 系列適用邏輯相同;WP_POST_REVISIONS 效果也一樣,但多站環境下記憶體預設值官方文件另外標示為 64MB(比單站的 40MB 高),建議設定時抓更高一點的餘裕。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|廠商官方:

Editing wp-config.php – Advanced Administration Handbook — 2026-07-10 查證(頁面標示最後更新 2026-01-07)
Debugging in WordPress – Advanced Administration Handbook — 2026-07-10 查證

⚠️ 本文核心事實以第一級官方文件為準。

📅 本文查證戳記:2026-07-10 依據 WordPress 官方開發文件(Advanced Administration Handbook,2026-01-07 更新版)撰寫,未涉及站長第一手實測數據,設定方式與預設值皆逐條對回官方原文。
若你的主機環境有不同的預設行為,歡迎在留言區回報,站長會更新文章。