看到「Allowed memory size exhausted」這行錯誤，最直覺的做法是把 WP_MEMORY_LIMIT 調大，換一個更大的數字。但這其實只是換一個更大的水桶去接漏水，水該滴的地方還是會滴。網站當下跳出 WordPress 記憶體耗盡的錯誤時，前台可能白畫面、後台可能連登入都進不去，越急著處理，越容易只做半套。
WordPress 記憶體耗盡指的是某段 PHP 程式碼想用的記憶體，超過了伺服器或 WordPress 允許的上限，程式碼因此被迫中止。真正該先確認的是誰在吃記憶體，而不是上限該調多高——如果元凶是某支寫壞的外掛，單純調高上限只是讓它多撐一陣子，之後照樣會撞到新的天花板。
這篇先教怎麼用工具找出真正在吃記憶體的元凶，再回頭談三種調整上限的做法怎麼選，以及調完之後如果錯誤還在，通常是卡在哪一層。
「Allowed memory size exhausted」是什麼錯誤？為什麼常常只看到「發生嚴重錯誤」？
某個頁面還沒跑完，程式就被硬生生攔下來，畫面只留下一行陌生的英文，這就是 WordPress 記憶體耗盡最典型的現場。完整的錯誤訊息通常長這樣：
Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes)Code language: plaintext (plaintext)第一段數字是伺服器目前允許單一支 PHP 程式使用的記憶體上限，以位元組計算；第二段是這支程式想再多要一點記憶體卻要不到的量。換句話說，不是網站壞掉了，而是 PHP 主動把這支程式擋下來，避免一段寫壞的迴圈或一次載入過多資料，把整台伺服器的記憶體吃光。
不過近幾年，前台多半看不到這麼完整的訊息，只會顯示一句「這個網站發生嚴重錯誤」。根據 WordPress 官方文件，這是站台碰到嚴重錯誤時內建的保護機制，目的是避免把伺服器路徑、外掛名稱這類技術細節暴露給一般訪客。真正的錯誤內容不會消失，只是換了地方留存，WordPress 通常會把細節寄一封信到網站管理員信箱，信件裡會附上出錯的檔案與行號。
如果信箱裡沒收到，或想直接查歷史紀錄，可以在 wp-config.php 開啟除錯紀錄，把下面幾行加進去，建議寫在「停止編輯」那行提示之前：
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Code language: PHP (php)這三行分別代表啟用除錯模式、把錯誤寫進紀錄檔，但不要顯示在前台頁面上，原理跟前面講的保護機制一樣。設定好之後重現一次錯誤，再打開 wp-content 資料夾底下的 debug.log，裡面會照時間排列每一次的錯誤，找到跟 Allowed memory size exhausted 同一時間點的那幾行，通常就能看到是哪個外掛或佈景主題的哪支檔案在觸發問題。
記憶體卡在哪一層？PHP memory_limit 和 WP_MEMORY_LIMIT 有什麼差異？
抓到觸發問題的元凶之後，接下來要處理的是記憶體上限本身。它其實疊了三層，把三層之間的關係搞清楚，才不會白調。
- 伺服器層的 PHP memory_limit：這是主機商在 php.ini 設定的天花板，自己在 WordPress 後台或 wp-config.php 裡怎麼調整都沒用，因為它是最終極限。只要主機沒特別調整，根據 PHP 官方手冊，這個值的預設是 128MB，用途是限制單一支程式可配置的最大記憶體量，避免寫壞的程式吃光伺服器資源。
- WordPress 層的 WP_MEMORY_LIMIT：這是 WordPress 分配給前台一般頁面請求的記憶體額度，只能在剛才那道天花板以下設定。WordPress 官方文件指出，WordPress 載入時本身就會嘗試把單一網站的額度拉到 40MB、多站點網路拉到 64MB，如果主機本來配置的就更寬裕，WordPress 也不會硬把額度壓低。
- 後台層的 WP_MAX_MEMORY_LIMIT：安裝外掛、批次更新、匯入大量資料這類後台操作，通常比訪客瀏覽前台頁面吃掉更多記憶體，所以 WordPress 讓後台可以另外設定一個比前台更高的額度。
三者的關係由小到大排列：WP_MEMORY_LIMIT 要小於或等於 WP_MAX_MEMORY_LIMIT，WP_MAX_MEMORY_LIMIT 又要小於或等於 PHP memory_limit。任何一層想設得比 PHP memory_limit 高，實際上都不會生效，因為最上面那道天花板才是真正的終點。這也是為什麼有些人把 WP_MEMORY_LIMIT 改到 512MB，錯誤照樣跳出來，原因往往出在主機的 PHP memory_limit 根本沒有那麼高。
錯誤發生時，網站會變成怎樣？為什麼得優先處理？
搞懂三層關係之前，這個錯誤已經先讓不少人吃了苦頭。訪客打開網站，看到的可能只是一片空白，或是那句「這個網站發生嚴重錯誤」；換成是你自己要登入後台，遇到的狀況常常更麻煩，連登入畫面都跑不出來，整個後台動彈不得。這兩種情況剛好對應前面講的兩層額度：前台白畫面多半是 WP_MEMORY_LIMIT 被用光，後台打不開通常是 WP_MAX_MEMORY_LIMIT 撐不住那次操作的用量。
常見的觸發情境有幾種：安裝一支功能較重的新外掛，初始化要一次載入大量程式碼與資源；用 CSV 批次匯入商品或會員名單，資料筆數一多就把記憶體吃滿；上傳解析度很高的圖片或批次產生縮圖，整張圖要攤開在記憶體裡運算；或是核心、外掛、佈景主題一起排隊更新，好幾個程序疊在同一個請求裡跑。
之所以不能先擱著，是因為一旦後台被鎖住，連你自己都進不去修。這時候只能透過 FTP 或主機的檔案總管，直接改設定檔或先停用可疑外掛。拖得越久，影響的範圍就越大，尤其網站上還掛著金流或表單這類即時服務，訪客多看一次嚴重錯誤，就多流失一次成交或名單的機會。
先別急著調高限制，這樣揪出真正吃記憶體的元凶
問題緊急歸緊急，第一步卻不是把上限調大，而是回頭確認記憶體被哪個環節吃掉。這裡有兩個工具能幫上忙，而且都比土法煉鋼把外掛一個個停用再測試快得多。
第一個是 WordPress 內建的健康狀態檢查：進到後台的「工具」>「網站健康狀態」，點開「資訊」分頁，再展開裡面的「伺服器」區塊，就能看到主機實際的伺服器架構與多項 PHP 環境變數，包括這台主機真正生效的記憶體上限是多少。這個數字是後續判斷的基準值，不管 wp-config.php 裡怎麼設，最終都不能超過這裡看到的數字。
第二個是安裝一支開發者診斷外掛，像 Query Monitor 這類工具，裝好啟用之後，只要用有管理員權限的帳號登入，管理列上就會直接顯示這次頁面的產生時間與尖峰記憶體用量，不用另外查任何紀錄檔。點開這行摘要，還能依外掛或佈景主題把資料庫查詢與 PHP 錯誤分類呈現，直接看出是哪一支外掛的哪個功能在拖慢速度、佔用最多記憶體，而不必自己一個一個停用外掛去試錯。
找到真正的元凶之後，判斷的順序通常是這樣：先確認那支外掛有沒有更新到最新版本，不少記憶體用量偏高的問題，作者其實已經在後續版本修掉了；版本已經最新卻還是吃很兇，考慮換一支功能相近但更輕量的替代品；真的一時找不到替代方案，就先停用觀察一段時間，確認錯誤真的消失，再回頭決定要不要保留這支外掛的功能。
診斷完才輪到調高限制：三種方法怎麼選？
如果診斷後發現不是壞掉的外掛在搞鬼，而是網站規模本來就需要更多記憶體，例如流量成長了、後台批次作業變得頻繁，這時候才輪到調整上限。以下三種方法依權限層級由淺入深，但不是每一種在你的主機環境都能生效，選之前先確認自己有沒有對應的存取權限。
方法一：改 wp-config.php，多數虛擬主機都能用
這是最多主機都適用的方法，因為 wp-config.php 是 WordPress 安裝時就存在的核心設定檔，幾乎每一種主機都能透過 FTP 軟體或主機商提供的檔案總管連進去改。打開這支檔案之前，先複製一份備份，因為這支檔案改壞，輕則某個設定失效，重則整個網站直接打不開。
找到檔案裡「停止編輯」那行提示，通常寫著類似「就這樣，不要再繼續編輯了」的英文註解，在它之前的位置加入下面兩行：
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );Code language: PHP (php)第一行設定前台一般頁面的額度，第二行設定後台的額度，數字可以依實際需求調整，但都要記得，不管怎麼設，最終都不能超過主機的 PHP memory_limit，這點在下一節會再談。
方法二：改 .htaccess，但只對 Apache 主機有效
.htaccess 是 Apache 伺服器讀取的設定檔，通常放在網站根目錄，一樣可以用 FTP 或檔案總管打開編輯。想調整記憶體上限，可以在檔案裡加入這一行：
php_value memory_limit 256MCode language: plaintext (plaintext)這個方法的限制要先講清楚，免得白改一場。php_value 這種寫法只在主機用 Apache 搭配 mod_php 執行 PHP 的環境才有效，如果主機用的是 PHP-FPM 或 Nginx，同一行設定寫進去不會出現任何錯誤訊息，但也完全不會生效。這種「改了卻沒用」最容易讓人誤以為是自己哪裡打錯字，結果反覆修改同一行浪費時間。想確認自己的主機用哪種執行模式，可以直接問主機商的客服，或參考下一節提到的網站健康狀態對照結果。
方法三：改 php.ini，或直接找主機商
自己架設的 php.ini、cPanel 後台附的 PHP 設定工具，或是有管理權限的 VPS，這些環境都能直接找到 memory_limit 這一行，把數值改成想要的上限：
memory_limit = 256MCode language: plaintext (plaintext)改完通常要重新啟動 PHP 服務，或等主機自動套用，才會生效。
多數共用虛擬主機不開放使用者自己碰 php.ini，這種情況與其含糊地跟客服說「網站跑不動」，不如把診斷出來的具體資訊講清楚：目前的 PHP memory_limit 是多少，可以從網站健康狀態的伺服器區塊查到、想調到多少，以及是為了排除哪個錯誤。資訊給得越精準，主機商能處理的速度通常也越快。
調高限制後錯誤還在？多半是卡在主機的天花板
把上限調到主機允許的範圍內之後，理論上錯誤該消失了。但如果把 wp-config.php 裡的數字越改越大，錯誤卻還是跳出來，這通常是整個問題最容易卡關的地方，真正卡住的往往不是這個檔案裡的設定，而是主機那一層的天花板。
前面提過，WP_MEMORY_LIMIT 永遠不能超過主機的 PHP memory_limit。WordPress 官方文件也提到，WordPress 載入時其實會自動檢查 PHP 目前實際配置的記憶體有沒有低於你設定的那個值，如果主機根本沒給那麼多，你設定的數字就只是寫好看的，實際上完全沒有意義。
想知道自己是不是卡在這一層，最快的辦法還是回到網站健康狀態的資訊分頁，展開伺服器區塊，把裡面顯示的 PHP 記憶體上限，拿來跟你在 wp-config.php 裡設定的數字對照。兩個數字一致，代表設定真的生效了；如果 wp-config.php 寫的是 512MB，網站健康狀態卻只顯示 128MB 或 256MB，就代表被主機那道天花板卡住，問題不在你的設定檔，而在主機本身允許的上限。
這種情況下，與其繼續加大 wp-config.php 裡的數字，不如直接把目前查到的兩個數字都附給主機商：現在網站健康狀態顯示的上限是多少、你想調整到多少。講得越具體，主機商越容易判斷這是共用主機方案本身的限制，還是可以直接幫你調整的設定，不用來回猜測浪費時間。
記憶體上限從來不是調得越高就越保險。真正讓網站穩下來的，是先把吃掉記憶體的那個元凶揪出來，再決定要不要調整、調到多少，上限本身只是一道安全閥，不是問題的答案。下次 WordPress 又跳出記憶體耗盡的錯誤，先打開診斷工具看一眼，再動手改設定檔，會比直接把數字往上疊有用得多。