根本原因是变量累积、对象未释放、框架缓存未关闭、连接未复用或gc未触发；cli进程不退出导致db连接、orm实例、日志缓冲等持续滞留，而php-fpm请求结束会自动回收内存。
CLI 模式下常驻进程消费 RabbitMQ，内存持续上涨最终溢出，根本原因不是“没给够内存”，而是变量累积、对象未释放、框架缓存未关闭、连接未复用或 GC 未触发。单纯调大 memory_limit 只是掩盖问题，且可能让进程撑到几 GB 后才崩溃。
为什么 CLI 消费者会内存越跑越大？
PHP-FPM 请求结束自动回收内存，但 CLI 进程不退出，所有变量、查询记录、ORM 实例、日志缓冲、甚至 require 过的类定义都会滞留。RabbitMQ 消费者典型场景中，以下行为会快速堆积内存：
- 每次 consume 回调里 new 一个新数据库连接（或没显式 close）
- 使用 Laravel/Eloquent 或 CI 的 DB 类，默认开启
save_queries = true，每查一次 SQL 就往内存里 append 一条日志 - 把整条消息 body 解成大数组后又赋值给类属性（如
$this->payload = json_decode($msg->body, true)），而该实例生命周期覆盖整个进程 - 循环中用
$items[] = $item累积处理结果，却没在每轮结束后unset($items) - 启用了
xdebug.mode=debug或opcache.enable_cli=1，opcode 缓存和调试器元数据不会随请求清空
如何让每条消息处理完就释放干净？
核心思路：把「单次消息处理」变成一个可隔离、可重入、无状态的小单元。不要依赖类属性跨消息保存数据，也不要让 DB/Logger/Config 实例长期存活。
- 在消息回调函数最开头加
gc_collect_cycles()，强制触发垃圾回收（尤其有循环引用时） - 用
unset()显式销毁大变量，比如unset($data, $result, $payload)；别指望自动 GC 在 CLI 下及时工作 - 数据库操作改用原生 PDO 或 mysqli，并在事务结束后立即
$pdo = null（不是只$pdo->close()） - 禁用框架的查询日志：CI 中设
$this->db->save_queries = false；Laravel 中可在config/database.php的 connection 下加'logging' => false - 避免在消费者类里 hold 大对象，比如不要把 ExcelReader、ZipArchive 实例挂到
$this上，而是在 handle() 内部 new + 用完即 destruct
要不要调大 memory_limit？怎么调才安全？
可以调，但必须分场景，且不能替代代码优化。CLI 下调内存限制最可靠的方式是启动参数，而非脚本内 ini_set() —— 后者在已接近上限时可能静默失败。
- 临时测试：运行命令改为
php -d memory_limit=512M consumer.php，不改任何配置文件 - 生产环境若需更高上限，建议设为固定值如
1G，而非-1（不限制），否则内存失控时进程可能被 OOM Killer 杀掉 -
ini_set('memory_limit', '512M')只对后续分配生效，无法回收已有内存；且若 php.ini 里设了硬上限（如256M），这个调用会被忽略 - 检查是否真需要大内存：在关键位置加
echo memory_get_peak_usage() . "\n"，确认峰值是否稳定在某值附近——如果每处理 10 条涨 1MB，说明还有泄漏没清
更彻底的兜底方案：定时重启消费者
再严谨的释放逻辑也难保 100% 干净，尤其引入第三方 SDK 或扩展后。对可靠性要求高的场景，应主动控制进程生命周期。
- 用
pcntl_signal(SIGTERM, ...)注册信号处理器，配合 supervisor 或 systemd 发送SIGTERM安全退出 - 设置消息处理计数阈值，例如每消费 500 条就
exit(0)，由进程管理器拉起新实例（supervisor 的autorestart=true+startsecs=0可做到无缝） - 避免在重启前正在处理的消息丢失：确保 RabbitMQ 的
ack是手动模式（no_ack=false），并在真正完成业务逻辑后再$channel->ack($msg->getDeliveryTag()) - 注意：不要用
sleep()做“等处理完再退”，CLI 没有请求上下文，sleep期间进程仍占内存
真正棘手的不是某次内存超限报错，而是泄漏点藏在框架底层或扩展里——比如某个 RabbitMQ 扩展内部缓存了 channel 实例，或者日志组件把每条消息的 trace_id 都塞进静态数组。上线前务必用 memory_get_peak_usage() 对比空跑和实际消费的内存差值，才能定位真实瓶颈。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
