应优先用php -d zend.enable_gc=0 composer install/update，因Composer依赖解析构建高密度嵌套对象图，GC周期与对象创建节奏恶性共振，导致内存峰值翻2–3倍；关闭GC后退至引用计数释放，更适配其短时强局部性任务。
开启 zend.enable_gc 反而让 Composer 内存暴涨，不是配置错了，是它和 Composer 的依赖解析逻辑在 GC 周期上发生了恶性共振。
为什么 zend.enable_gc=1 在 Composer 运行时反而更耗内存
Composer 的依赖解析（尤其是 composer install 或 update）会构建庞大的对象图：Package、Constraint、Repository、Pool……这些对象大量引用嵌套，且生命周期集中在单次执行中。PHP 垃圾回收器默认采用同步周期性检测（每 10000 次分配触发一次），但 Composer 在解析高峰时对象创建密度极高，GC 尚未运行，内存已持续攀升；等 GC 终于启动，又因图结构复杂、遍历开销大，反而卡住主线程、延迟释放，造成“假性泄漏”现象。这不是内存泄露，是 GC 节奏和负载不匹配。
常见表现：Allowed memory size of XXX bytes exhausted 错误在启用 GC 后更频繁，甚至加到 4G 仍失败；memory_get_peak_usage() 显示峰值比关闭 GC 时高 2–3 倍。
- PHP 7.4+ 默认开启
zend.enable_gc=1，但 Composer 2.x 并未适配这种节奏 - GC 关闭后，PHP 退回到引用计数释放模式——对 Composer 这类短时、强局部性的任务反而更轻量
- 该问题在
composer update（全图重算）时比install更明显
临时禁用 GC 的安全操作方式
直接改 php.ini 影响全局，不现实；用 -d 参数只作用于当前命令最稳妥。注意：这是针对 Composer 进程本身的 PHP 配置覆盖，不影响其他 PHP 服务。
立即学习“PHP免费学习笔记（深入）”；
- 运行前加
-d zend.enable_gc=0：例如php -d zend.enable_gc=0 composer.phar update - 若用系统级
composer命令，需确认它是否封装了php调用；推荐直接调用php执行 phar 文件，避免 shell wrapper 干扰 - 不建议在
composer.json中设config.platform.php来绕过，那只是声明版本，不控制运行时 GC
验证 GC 状态与内存变化的快速方法
别猜，用一行命令确认当前 Composer 进程是否真的关掉了 GC：
php -d zend.enable_gc=0 -r "echo gc_enabled() ? 'on' : 'off'; echo PHP_EOL; echo memory_get_peak_usage(true) / 1024 / 1024 . ' MB';"
对比开启和关闭时的输出，能清晰看到 gc_enabled() 返回值和内存峰值差异。注意：必须用 memory_get_peak_usage(true)（真实内存），而非默认的 false（脚本内存），因为 Composer 大量使用扩展分配。
- 如果返回
on，说明-d参数没生效，检查是否被php.ini中的engine=On或其他 ini 文件覆盖 - 某些 Docker 环境中，
php -c /dev/null可强制清空所有 ini 加载，再叠加-d更可靠
长期项目中的兼容性提醒
这个方案治标不治本，但它目前是最小侵入、最有效的缓解手段。PHP 8.3+ 已引入异步 GC（gc_enable_async()），但 Composer 主干尚未适配；如果你在 CI 流水线中遇到 OOM，别急着升级内存，先加 -d zend.enable_gc=0 —— 它不会影响依赖正确性，只是换了一种释放策略。
真正容易被忽略的是：某些自定义插件或私有仓库的 PluginInterface 实现，如果内部缓存了大量 Package 对象并长期持有引用，即使 GC 关闭，也会拖慢释放。这类问题得看插件代码本身，和 zend.enable_gc 无关。
