WordPress 报 Allowed memory size exhausted：先抓堆栈找吃内存的插件，再改 memory_limit

后台保存商品、导入 CSV，或某次打开仪表盘时，页面突然断掉，服务器日志或 WP 调试输出里出现：

复制代码

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted
(tried to allocate 20480 bytes) in .../wp-content/plugins/.../xxx.php on line N

这不是「白屏随便猜插件」的同款流程，也不是 Heartbeat 刷 CPU。核心是：某次请求在达到 PHP memory_limit 前把内存吃光了 。更稳的顺序是：先从堆栈 / 文件路径锁定嫌疑插件或主题，再用二分确认元凶，最后才考虑提高 WP_MEMORY_LIMIT / php.ini memory_limit------并且要能回滚。盲目把内存加到 512M、1G，往往只是把「当场炸」推迟成「偶尔更慢地炸」。

先读堆栈：debug.log / 报错行指向哪里

生产上若尚未开调试，先在可回滚的前提下临时打开日志（改完务必关回）：

php 复制代码

// wp-config.php（放在「That's all, stop editing!」之前）
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false); // 前台不要直接吐 Fatal
@ini_set('display_errors', 0);

复现一次出错操作后，打开 wp-content/debug.log，盯住 Fatal 行里的路径：

wp-content/plugins/某插件/... → 优先怀疑该插件（或其依赖的大数组/一次性加载）
wp-content/themes/某主题/... → 主题或子主题里的重查询 / 递归
wp-includes/ 或核心文件 → 多半是上游插件通过 hook 间接撑爆，仍要结合调用栈往上追

若装了 Query Monitor，在能进后台的页面上看 Overview / Memory 与 Queries ：峰值内存、是否单页上千查询、是否某组件一次性 get_posts(-1)。Fatal 发生在请求中途时，QM 可能来不及渲染，此时 debug.log 堆栈 + 插件二分 更可靠。

把 Fatal 行、前后几十行、复现步骤记进工单，后面改 memory_limit 时才有对照基线。

二分插件 / 主题：确认谁在吃内存

堆栈已经点名某插件时，仍建议用排障模式或逐个停用验证，避免「路径碰巧经过该文件」的误判：

有 staging：在预发复现；生产只读日志、少改。
无 staging：维护窗口；先完整备份（文件 + 库）。用健康检查「排障模式」或 FTP/面板只留默认主题 + 必要插件，再按批启用。
每次只恢复一批插件，复现同一操作（同一导入文件、同一商品保存）。哪一批再次触发 Fatal，再拆到单个插件。
主题嫌疑：切到默认主题（如 Twenty Twenty-Five）对比；若默认主题下不再炸，再查子主题 functions.php、页建器全局查询。

常见元凶模式（便于对照，不是点名某商业插件）：

导入/同步类：一次把整表 CSV / API 结果载入数组
页建器或 SEO 批量：后台列表页生成大量元数据
报表/统计：未分页的 WP_Query / 原始 SQL
图片处理：超大原图一次性解码进内存

定位到插件后，优先看是否有「分批 / 降低并发 / 排除某 CPT」设置；能关的重功能先关，再谈加内存。需要把「冲突、停用顺序、排障模式」和别的 Fatal 白屏场景放在同一套流程里对照时，可参考 WordPress 插件冲突排查，先缩小范围再改主机参数。

再调 memory_limit：wp-config 与 php.ini，以及何时不该加

只有在你已经知道「谁在吃」或至少确认「合理峰值确实高于当前上限」时，再上调限额。WordPress 相关常量与 PHP 实际上限的关系要分清：

php 复制代码

// wp-config.php
define('WP_MEMORY_LIMIT', '256M');      // 前台 / 常规请求目标
define('WP_MAX_MEMORY_LIMIT', '512M');  // 后台等「提高后」目标

同时检查 PHP 真实上限 （面板 php.ini、.user.ini、或 php-fpm pool）：

ini 复制代码

memory_limit = 256M

注意：

WP_MEMORY_LIMIT 不能突破 PHP memory_limit；只改 WP 常量、php.ini 仍是 128M，请求照样在 128M 挂掉。
共享主机常有面板级硬顶；改完用 phpinfo() 或临时 error_log(ini_get('memory_limit')) 确认生效的是哪个值。
不要把生产一次性调到 1G「先看着」：掩盖泄漏、拖垮同机其它站点，且 OOM killer 可能直接杀 php-fpm。
变更前记下旧值；工单里写回滚步骤（改回原 memory_limit / 去掉常量 / 重载 php-fpm）。

若堆栈指向「一次加载全部行」的导入逻辑，加内存只是买时间：应改分批导入、提高 batch size 上限外的批次数、或换 WP-CLI 分片命令。根因是查询/算法时，加内存几乎无效。

验收清单

debug.log（或主机 PHP 错误日志）已保存 Fatal 全文与文件:行号；能指向插件/主题路径或可追的 hook
已用排障模式 / 分批启用确认元凶；不是「关掉一半插件碰运气」且无法复述结论
已区分：修插件设置 / 换实现 vs 仅提高限额；后者有旧值记录与回滚步骤
WP_MEMORY_LIMIT / WP_MAX_MEMORY_LIMIT 与 php.ini memory_limit 一致或后者更高；php-fpm/面板已重载并复查
复现原操作：不再 Fatal；抽查内存峰值（QM 或日志）是否仍异常飙升
WP_DEBUG_DISPLAY 保持关闭；临时调试配置已收回；备份点可回滚

Allowed memory size exhausted 时，先让堆栈说话、再二分坐实、最后才动 memory_limit，比一上来加内存更可控，也更不容易把泄漏留在生产里。