gc_disable() 能让 Composer 快起来，是因为它避免了 autoload 过程中频繁却无效的 GC 扫描，将回收延迟至加载完成后的精准清理。
为什么 gc_disable() 能让 Composer 快起来
Composer 在解析依赖、构建 classmap、注册大量 autoload 回调时，会密集创建 stdClass、array 和闭包对象，这些对象常含嵌套引用（比如 use 捕获的上下文），迅速填满 PHP 的根缓冲区（root buffer）。但默认 GC 阈值是 10000，而 Composer 加载过程往往只累积到 8000+ 就暂停——GC 不触发，临时对象滞留，后续又不断新建，形成“边建边扫、扫不出东西”的空转。禁用 GC 不是绕过问题，而是把回收时机从“频繁无效扫描”挪到“加载完成后的精准清理”。
在哪儿加 gc_disable() 才有效
必须加在 vendor/autoload.php 被 require 之前，且越早越好——比如 public/index.php 或 bin/console 的第一行。加晚了（如在 require 之后）或加错位置（如放在框架初始化后），就起不到阻断 autoload 阶段 GC 触发的作用。
- ✅ 正确位置：
gc_disable(); require __DIR__.'/../vendor/autoload.php';
- ❌ 错误位置：在
new Application()之后、在App::boot()内部、或写在composer.json的autoload配置里 - ⚠️ CLI 场景注意：如果用
php -d memory_limit=-1 composer.phar install，那gc_disable()要写在composer.phar自身代码里（不推荐改源码），更稳妥的做法是升级到 Composer 2.5+，它已默认在关键路径插入gc_disable()
gc_collect_cycles() 什么时候该手动调
不是每次请求都调，也不是 autoload 后立刻无脑调。它只应在明确知道“刚完成一批高引用密度操作、且当前无活跃业务逻辑”时执行——比如 autoload 完成后、框架容器尚未构建前的空档期。
- ✅ 推荐组合：
gc_disable(); require __DIR__.'/../vendor/autoload.php'; gc_set_threshold(3000); // PHP 8.1+ gc_collect_cycles(); // 此时 root_buffer_length 通常 > 8000，能真正清掉 autoload 产生的垃圾
- ❌ 常见误用：在循环中反复调用；在 Swoole worker 每次请求开头调（干扰长生命周期内存管理）；在
__destruct()里调（可能引发不可预测的 GC 状态） - ⚠️ 注意：PHP 8.4+ 启用增量 GC 后，
gc_collect_cycles()行为有变，返回值不再代表“回收对象数”，而是“是否完成一轮完整扫描”，需结合gc_status()['collected']判断效果
别忽略 autoload 机制本身埋的循环引用雷
GC 变慢的表因是触发频繁，根因常是 autoload 拉进来的第三方包存在隐式循环引用——比如 Monolog 的 Handler 和 Formatter 互相持有，或 Symfony DI 容器在编译阶段生成的代理类与原始类构成闭环。这类问题不会在 composer install 时报错，但会在 FPM worker 运行几小时后让 gc_status()['roots'] 持续 > 9500，且 gc_collect_cycles() 返回 0。
立即学习“PHP免费学习笔记（深入）”；
- 排查线索：
php -d zend.gc_debug=1 script.php看输出里是否高频出现gc_collect_cycles() returned 0 - 验证方式：临时注释掉
require vendor/autoload.php，用class_alias()或include_once手动加载核心类，观察内存是否平稳 - 修复方向：优先升级到已修复循环引用的包版本（查 GitHub Issues 关键词 “circular reference gc”）；避免在
config/中用ArrayObject或WeakMap封装全局配置；禁用 dev 包的 PSR-4 映射（如 PHPUnit 的"autoload-dev": {"psr-4": {"Tests\": "tests/"}}若被误引入生产 autoload chain）
