後台按下更新外掛，畫面卻變成一片空白；或是上傳一張大圖，網站直接回你「Allowed memory size of 134217728 bytes exhausted」。這多半不是網站壞掉，而是 PHP memory_limit 用盡了。WordPress 跑在 PHP 上，每一次請求都要向伺服器借一塊記憶體來組裝頁面，借到的額度一旦超過上限，PHP 就會中斷執行，留給你一片白畫面或一行紅字。

麻煩的是，這個問題有三個常被搞混的設定值，網路上多數教學只叫你「在 wp-config.php 加一行 512M」，卻沒說清楚為什麼很多人加了沒用。本文會先帶你確認白畫面到底是不是記憶體造成的，再說明 PHP memory_limit、WP_MEMORY_LIMIT、WP_MAX_MEMORY_LIMIT 三者的關係，接著給出 wp-config.php、php.ini、.htaccess、cPanel 四種調整方法以及各自適用的環境，最後談怎麼找出真正吃記憶體的元兇，避免你把數字越調越大卻治標不治本。

PHP memory_limit 到底是什麼，為什麼會不足

PHP memory_limit 是伺服器層級的設定，規定「單一支 PHP 程式在執行期間最多能用多少記憶體」。WordPress 每收到一個請求，PHP 就會啟動一支程式去查資料庫、跑外掛邏輯、套用佈景主題、組出 HTML，這整個過程都要佔用記憶體。當主題、外掛或某段程式碼累積的用量超過 memory_limit，PHP 會立刻丟出致命錯誤並停止，於是頁面就空了。

記憶體不足通常不是 WordPress 本身的問題，而是下列情況把用量推高：

• 外掛過多或外掛寫得不好：一支設計不良的外掛可能在單一請求裡反覆載入大量資料，或發生記憶體洩漏，把額度一口氣吃光。
• 上傳或處理大型媒體：上傳高解析度圖片時，PHP 要把整張圖讀進記憶體做縮圖與壓縮，圖越大佔用越高。
• WooCommerce 等重量級功能：商品數量多、串接多個外掛時，後台的訂單查詢、報表、批次匯入都很耗記憶體。
• 主機額度本來就偏低：共享主機為了讓一台機器塞下很多網站，常把每個帳號的 PHP 記憶體壓在 64M 甚至更低。

WordPress 預設會試著把記憶體拉到至少 64M，但對裝了現代主題與多支外掛的網站來說，這個底線經常不夠用。

三個記憶體設定值的關係，先搞懂誰管得到誰

調整前一定要先弄清楚三個值的階層，否則很容易發生「明明設了 512M 卻完全沒效」的窘境。

伺服器的 PHP memory_limit 是真正的天花板，由主機商在 php.ini 或主機面板裡控制；WordPress 的兩個常數只是「向 PHP 申請」這麼多記憶體，申請值永遠不可能超過伺服器給的上限。換句話說，主機把 PHP memory_limit 卡在 128M，你在 wp-config.php 寫 512M 也只能用到 128M。

WordPress 之所以分成兩個常數，是因為後台作業（更新外掛、處理圖片、匯入內容）比前台顯示頁面耗記憶體得多。WP_MEMORY_LIMIT 管前台、WP_MAX_MEMORY_LIMIT 管後台，後者預設就比前者高。要特別記住的是，這兩個 WordPress 常數都被伺服器的 PHP memory_limit 壓著，伺服器不放行，WordPress 怎麼設都沒用。

理解這層關係後，排查邏輯就清楚了：先想辦法把伺服器的 PHP memory_limit 拉高，再用 WordPress 常數去申請足夠的額度；如果伺服器那層動不了，剩下的就只能調整外掛或升級主機。

白畫面不一定是記憶體，先把真正的錯誤訊息找出來

看到白畫面別急著改記憶體，先確認它到底是不是記憶體造成的。白畫面（業界俗稱 WSOD，White Screen of Death）只是 PHP 發生致命錯誤後的共同結果，記憶體不足會白畫面，外掛衝突、主題函式寫錯、PHP 版本不相容同樣會白畫面。直接亂調記憶體，可能根本沒對到症。

新版 WordPress 基於安全考量，預設不會把錯誤細節印在畫面上，而是顯示「網站發生重大錯誤」這類籠統訊息，真正的原因被藏在背景。要把它挖出來，有三個管道：

• 查網站管理員信箱：新版 WordPress 偵測到致命錯誤時，會寄一封主旨類似「你的網站發生技術問題」的信到管理員信箱，裡面會指出是哪支外掛或主題出錯，信末通常附上完整錯誤訊息。
• 打開除錯日誌：在 wp-config.php 的 stop editing 那行之前加入下列三行，WordPress 就會把錯誤寫進 wp-content/debug.log，而不顯示在前台：

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

• 看主機的錯誤日誌：到主機面板（cPanel 的錯誤記錄、或 Plesk 對應功能）查看 PHP error log，記憶體不足的訊息會像這樣：PHP Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate ... bytes)。

關鍵字就是 Allowed memory size 加上 exhausted。日誌裡看到這兩個字，才確定是記憶體問題，可以往下走調整流程；若看到的是某支外掛的函式錯誤或 PHP 版本警告，那要走外掛排查或升級 PHP，調記憶體幫不上忙。除錯日誌建議只在排查期間打開，找到原因就把 WP_DEBUG 改回 false，避免錯誤細節長期暴露。

動手前先確認目前的記憶體額度是多少

知道現況才知道要不要調、調多少，否則容易調過頭。WordPress 內建幾個地方可以直接看到目前的限制：

到後台「工具 → 網站狀態 → 資訊」展開「伺服器」區塊，可以看到 PHP 記憶體限制（伺服器層級）與 WordPress 記憶體限制兩個數字。若你有裝 WooCommerce，到「WooCommerce → 狀態 → 系統狀態」會更清楚，伺服器環境區的 PHP memory limit 是伺服器額度，WordPress 環境區的 WP memory limit 是 WordPress 申請值，兩個分開列，一眼就能判斷是哪一層卡住。

判讀原則很簡單：如果 PHP 記憶體限制（伺服器那層）已經偏低，例如只有 64M，那要先處理伺服器層級；如果伺服器層級夠高、但 WordPress 記憶體限制偏低，那只要動 wp-config.php 就好。先看清楚再決定改哪裡，是省下反覆試錯的最快方法。

調整記憶體的四種方法，依主機環境選一個

下面四種方法從最常用、風險最低的排到比較進階的。改任何設定檔之前，務必先備份該檔案或整站，改錯了才能還原。

方法一：修改 wp-config.php 申請更多記憶體

這是最常見也最安全的做法，適用於伺服器額度足夠、只是 WordPress 申請值偏低的情況。用主機檔案管理員或 FTP 工具打開網站根目錄（通常是 public_html）裡的 wp-config.php，在 /* That's all, stop editing! Happy publishing. */ 這行之前加上：

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

第一行把前台額度拉到 256M，第二行把後台額度拉到 512M。一定要加在 stop editing 那行之前，加在後面不會生效。存檔後清掉瀏覽器快取再重新整理網站，如果錯誤消失就成功了。要是還在報錯，多半是撞到伺服器的 PHP memory_limit 上限，得往方法二、三或四走。

方法二：在 php.ini 提高伺服器層級的上限

php.ini 是 PHP 的主設定檔，直接管伺服器層級的 memory_limit，這才是真正的天花板。如果根目錄找得到 php.ini（部分主機允許使用者自建），打開後找到 memory_limit 那行，把值改高：

memory_limit = 256M

存檔後重新整理網站確認。要注意兩件事：其一，php.ini 是系統設定檔，純網站設計者若沒有系統管理權限，通常無法直接改，這時得改用其他方法或請主機商代調；其二，這個檔案的設定會影響該主機上的相關網站，且數字不宜一次拉太高，萬一遇到設計不良的程式碼把整台機器的記憶體吃光，會拖累整體效能，反而得不償失。256M 對多數網站已相當充裕，先從這個值試起。

方法三：在 .htaccess 覆寫（限 Apache + mod_php）

如果碰不到 php.ini，可以試著在根目錄的 .htaccess 裡覆寫。在 # END WordPress 那行之前加上：

php_value memory_limit 256M

但這個方法有明確的適用前提：只有在 Apache 搭配 mod_php 的環境才有效。如果你的主機跑的是 PHP-FPM 或 Nginx，這行不但不會生效，有些設定下還會讓整站噴 500 錯誤。加完若網站變得無法存取，先把這行刪掉還原，代表你的環境不吃 .htaccess 這套，改走方法二或四。

方法四：透過主機面板或直接請主機商調

對台灣多數使用共享主機的使用者來說，這往往是最實際的做法。cPanel 主機可以到「MultiPHP INI Editor」，選好網域後直接在介面把 memory_limit 拉高，免去手動編輯設定檔的風險。找不到這個工具、或主機把 PHP 記憶體鎖死的話，最快的解法就是開工單請主機商代為提高伺服器層級的 PHP memory_limit，多數主機商能很快處理。如果連主機商都說無法再往上調，那就是這個方案的資源已經到頂，該考慮升級方案了。

該設多少才夠，128M、256M 還是 512M

先給結論：一般部落格或內容網站 256M 足夠，WooCommerce 商店建議至少 256M、規模大的拉到 512M，沒事不必往上堆。記憶體不是設越大越好，過高的設定反而可能掩蓋掉真正失控的外掛問題。

實務上可以這樣抓：

• 小型部落格、形象網站：前台 128M、後台 256M 通常綽綽有餘。
• 一般商業網站、流量中等：以 256M 當起點，前台 256M、後台 512M 是穩當的組合。
• WooCommerce 商店：官方建議至少 256M；商品數破千、串接多個金流與多支擴充外掛時，512M 以上會比較安穩。

調整時遵守「夠用就好、漸進加碼」的原則：先設一個合理值，觀察錯誤是否消失、後台作業是否順暢，不夠再往上加一階，而不是一開始就塞 1024M。畢竟伺服器總記憶體有限，單一網站佔太多，會排擠到同主機的其他服務。

數字調上去還是報錯，先找出誰在吃記憶體

如果伺服器額度已經拉高、WordPress 常數也設足，錯誤卻還在，問題通常出在某支外掛或某段程式碼異常耗用記憶體，這時要做的是抓元兇，不是再把數字往上堆。

最直接的方法是逐一停用外掛來定位。先把所有外掛停用，確認網站恢復正常後，再一支一支重新啟用，每啟用一支就重整網站，當錯誤重新出現，那支剛啟用的外掛就是嫌疑犯。停掉它、找替代方案或回報外掛作者，比硬調記憶體治本得多。如果連後台都進不去，可以透過 FTP 把 wp-content/plugins 資料夾整個改名，強制停用全部外掛，再進後台逐一處理。

想更精準地看記憶體花在哪裡，可以安裝 Query Monitor 這類免費除錯外掛，它會列出每個頁面載入時各支外掛、各筆資料庫查詢消耗的資源，讓你直接看出是哪個環節在拖垮記憶體，而不是靠猜。找到具體原因後對症處理，往往比把 memory_limit 翻倍更能根治問題。

另一個常被忽略的面向是 PHP 版本。舊版 PHP 執行效率較差、也較耗記憶體，把網站升到目前受支援的穩定 PHP 版本，常常能順帶降低記憶體用量，安全性也更好。

把記憶體問題從救火變成預防

把這幾件事顧好，記憶體不足大多能在發生前就被擋下：定期檢視並停用沒在用的外掛、上傳前先壓縮大圖、裝一支快取外掛減少每次請求重新組頁的負擔，並讓 PHP 維持在受支援的版本。這些動作都在替每一次 PHP 請求省記憶體，比事後調高上限更治本。

回到最初的白畫面：正確的順序是先打開除錯日誌確認真的是記憶體問題，再用網站狀態看清楚是伺服器層級還是 WordPress 層級卡住，接著選對應環境的方法調整，最後用逐一停用外掛或 Query Monitor 找出真正的耗用源。把 PHP memory_limit 這條線理順，後台更新與大檔上傳就不會再動不動給你一片空白。下次遇到「Allowed memory size exhausted」，你已經知道該從哪一層下手，而不是盲目把數字越調越大。