gc_disable()能缓解Composer内存暴涨，因其在依赖求解阶段禁用PHP循环引用GC，避免GC频繁扫描大量短生命周期对象却无法回收，转而由OS内存分配器管理，实测峰值内存降30%~40%、Solver耗时缩短2倍以上。
为什么gc_disable()能缓解Composer内存暴涨
Composer在依赖求解阶段会创建大量临时对象（比如Package、Constraint、Rule），但这些对象生命周期极短，GC来不及回收就已被新对象覆盖。PHP的GC机制每执行一次都要扫描所有zval引用计数，而Solver阶段对象生成速率远高于GC触发阈值——结果是GC反复启动却几乎不释放内存，徒增CPU开销和内存碎片。gc_disable()不是绕过内存管理，而是让PHP把这部分压力交给OS级内存分配器（如glibc malloc），实测v2.5+版本中该改动使峰值内存下降30%~40%，且Solver耗时缩短2倍以上。
gc_disable()只对Composer CLI生效，不影响你的项目代码
这个调用发生在Composer主进程初始化阶段（src/Composer/Console/Application.php），仅作用于当前CLI进程。你项目里运行的PHP代码（比如Laravel请求、PHPUnit测试）完全不受影响，gc_collect_cycles()照常工作。常见误解是“关了GC整个PHP就失控”，其实只是禁用了当前进程的周期性垃圾收集器，内存仍由引用计数机制管理，只是不主动触发清理循环引用。
别手动调用gc_disable()，它已内置且不可绕过
Composer自2.2起默认启用gc_disable()，你无法通过配置关闭它。试图在composer.json或环境变量里干预只会失败。如果你观察到GC相关异常（比如gc_collect_cycles()返回0但内存持续上涨），问题一定不在Composer本身，而是：
- autoload路径重叠导致类加载器缓存污染，形成隐式循环引用
- require-dev包（如phpunit）错误声明了指向项目src的
psr-4映射 - 使用
class_alias()后未清理旧类名绑定，残留弱引用
这类问题必须从autoload配置和类设计层修复，不是调大memory_limit或换镜像能解决的。
真正要盯住的是autoload和依赖结构，不是GC开关
GC只是表象，根源永远在代码组织方式。比如两个包都声明"App\": "src/"，当class_exists('AppUser', false)被调用时，可能触发错误加载顺序，让AppUser和PHPUnitFrameworkTestCase互相持有实例；又或者dev包通过autoload-dev把测试工具类注入到生产autoloader里。这些才是内存缓慢爬升、最终OOM的元凶。检查方法很简单：composer dump-autoload --no-dev -v看是否报重复类警告，再用composer show -t确认依赖树里有没有同一包出现3次以上且路径不同。
