修复 WordPress 中的“Allowed Memory Size Exhausted”内存耗尽错误

如果你的站点报出 Fatal error: Allowed memory size of 268435456 bytes exhausted，请在 wp-config.php 的 /* That's all, stop editing! */ 注释上方加入这一行：define( 'WP_MEMORY_LIMIT', '256M' );。这能让大多数站点在一分钟内恢复访问。但在你离开之前，请把本页剩下的内容读完，因为提高内存上限只是一种诊断手段，而不是根治。如果崩溃在更高的数值上再次出现，真正的问题就是某段代码在无节制地消耗内存，而更高的上限只是给了它更多可以挥霍的空间。

这个错误到底是什么意思

PHP 会记录每个请求已经分配了多少内存。当单个请求试图分配的内存超过 php.ini 中设置的 memory_limit（或被 WordPress 覆盖后的值）时，PHP 会立即中止该请求并抛出致命错误，同时打印出它崩溃时的字节数。268435456 bytes 就是 256M，134217728 是 128M，536870912 是 512M。“tried to allocate”后面那个数字告诉你的是压垮骆驼的最后一根稻草有多大，而不是问题本身有多大。

WordPress 在 PHP 的限制之上又叠加了自己的一套限制。WP_MEMORY_LIMIT（默认 40M，如果 PHP 上限更高则取 PHP 的值）控制前台。WP_MAX_MEMORY_LIMIT（默认 256M）控制后台操作，比如多媒体库和插件更新，这些操作确实需要更多内存。WordPress 会在加载时根据这些常量调用 ini_set('memory_limit', ...)——但前提是你的主机允许 ini_set，而且最高也只能到主机设定的硬性上限。正是最后这一点，导致编辑 wp-config.php 有时看起来毫无作用。

按顺序修复

**1. 在 wp-config.php 中提高 WordPress 的内存上限。**这是第一个要尝试的办法，因为它可逆，而且不影响其他任何东西。

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

如果你不确定这些代码该放在哪里，或者想同时把其他常用常量也一并设置正确，我们的 wp-config 生成器 会生成一段干净的代码块供你粘贴。位置很关键——放在“stop editing”那一行下面的任何内容都会被忽略。

**2. 如果这样没有任何效果，说明是你的主机在限制 PHP。**请在 PHP 层面提高 memory_limit。在 php.ini 中：

memory_limit = 256M

在很多共享主机上你无法直接编辑 php.ini。可以改为在网站根目录放一个 .user.ini 文件，或者在 Apache/mod_php 环境下通过 .htaccess 设置：

php_value memory_limit 256M

注意，.htaccess 中的 php_value 在 nginx 或 PHP-FPM 环境下会抛出 500 错误，因为它是 Apache/mod_php 专用指令。如果你加上它之后出现 500 错误，原因就在这里——删掉它，改用 .user.ini。

**3. 确认实际生效的数值。**不要相信你编辑了什么，要相信 PHP 报告了什么。在网站根目录放一个只有一行的文件：

<?php echo ini_get('memory_limit');

在浏览器里打开它，读出数值，然后删除该文件。如果你设置了 256M 之后它仍然显示 128M，说明你的主机在覆盖你的设置，你需要联系主机商，或者使用他们控制面板里的设置项。

大多数指南都跳过的部分

提高内存上限是诊断。下面讲怎么解读结果。

如果你设为 256M 后，站点在正常流量下能稳定运行，说明你之前确实撞上了一个偏低的合理上限——这在拥有大型多媒体库、WooCommerce 或页面构建器的站点上很常见。到这里就搞定了。

如果你设为 256M 后又崩溃，再设为 512M 后还是崩溃，**就别再往上调了。**一个正常的 WordPress 请求不需要 512M。当内存占用不断攀升、没有上限时，说明有东西在循环或不断累积：某个插件把整张数据库表加载进了一个数组，某个 add_action 递归触发了自己，某个导入程序把每一行都同时留在内存里，或者两个插件在同一个钩子里互相打架。提高内存上限并不能修复无限循环——它只是把崩溃推迟了几秒钟，并让问题更难复现。

要找出罪魁祸首，请停用所有插件，并切换到一个默认主题，比如 Twenty Twenty-Four。如果错误消失了，就逐个重新启用，直到它再次出现。打开调试日志来捕捉它崩溃的位置：

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

wp-content/debug.log 中的那一行致命错误会指出分配了最后一块内存的文件名和行号。那里通常就是循环所在，或者离它只差一次函数调用。

不要做的事

**不要把 WP_MEMORY_LIMIT 设成 -1 或 1024M 然后就不管了。**无限的内存并不能修复泄漏；它只会让一个失控的请求吃掉整台服务器，从而拖垮同一台机器上的其他所有站点，然后招来主机商的电话。内存上限是一项安全机制，请保留它。

**不要把 ini_set('memory_limit', '512M') 粘进 functions.php 当作主要的修复手段。**对某些故障来说它运行得太晚了——如果崩溃发生在 WordPress 核心加载阶段、也就是在你主题的 functions.php 执行之前，那这一行根本不会运行。wp-config.php 加载得更早，才是正确的地方。

**不要想当然地认为这是主机问题就去升级套餐。**有时候确实是主机配置不足。但更常见的是同样的崩溃会跟着你到更大的套餐上，因为病根就藏在你的插件里一起搬过去了。先排除掉循环问题，这是免费的。

**不要用提高 memory_limit 的办法去修复 max_execution_time 错误。**它们是两种不同的限制，报的是不同的信息。内存耗尽会说“Allowed memory size … exhausted”，超时则会说“Maximum execution time … exceeded”。调错了那一个只会白白浪费你一个下午。

还是卡住了？

如果你已经确认实际生效的上限确实是 256M 或更高，也在停用所有插件、使用默认主题的情况下测试过，但内存仍然被耗尽，那你面对的就是一个真正值得在调试日志里追查的泄漏，而不是一个值得继续往上调的上限。抓下那一行致命错误，记下它指向的是哪个插件的目录，这就是你的 bug 报告。先用 wp-config 生成器 把你 wp-config.php 里的基础常量设置对，这样你才能确定这些限制真的被设在了你以为的地方——然后再去读日志。