镜像配置错误会导致gc问题被误判，实际是http超时阻塞autoloader初始化，并未进入对象创建阶段；真正触发gc压力的是php运行时代码而非composer cli本身。
镜像配置错误会导致 GC 问题被误判
换源失败后，composer install 卡在 Loading composer repositories 或反复重试元数据请求，容易让人以为是 GC 占用 CPU——其实只是 HTTP 超时阻塞了 autoloader 初始化，根本没走到对象创建阶段。真正触发 GC 压力的，永远是后续 PHP 进程里跑起来的代码，不是 Composer CLI 本身。
常见错配组合：
-
composer config -g repos.packagist（多了一个s）→ 配置写进去了但 Composer 不识别，仍连https://packagist.org，而该域名在国内常超时或被限流 -
composer config -g repo.packagist https://mirrors.aliyun.com/composer（缺末尾/）→ 请求变成https://mirrors.aliyun.com/composerpackages.json，返回 404 后 fallback 到官方源，延迟翻倍 - 项目级
composer.json中存在"packagist.org": false→ 全局镜像配置直接被无视，且不报错
清缓存不等于清 GC 压力
composer clear-cache 只删 ~/.composer/cache/files/、repo/、vcs/ 三个子目录，和 PHP 运行时 GC 完全无关。它不会释放任何正在运行的进程内存，也不会影响 gc_collect_cycles() 的行为。
但清错位置会放大误判风险：
- 删了
repo/packagist.org/→ 下次composer update必须重新拉packages.json和所有provider-*.json，HTTP 耗时增加 2–5 秒，看起来像“卡住”，实则是网络层延迟 - 删了
vcs/后又装dev-main包 → 重建 Git 裸库过程 I/O 密集，CPU 使用率短暂冲高，易被误读为 GC 在扫引用 - 在 CI 流程里无脑加
composer clear-cache→ 缓存无法复用，每次构建都从零下载，带宽和 TLS 握手开销叠加，拖慢整个 pipeline
autoload 加载路径重叠才是 GC 循环引用的温床
镜像本身不引入循环引用，但错误的 autoload 配置会在加载过程中悄悄打通回路。PSR-4 规则安全，问题出在跨包命名空间污染上。
典型场景：
- 某个
require-dev包（如phpunit/phpunit）的composer.json里写了"autoload": {"psr-4": {"App\": "../src/"}}→ 把你项目的src/加进了它的 autoloader；而你的业务代码又用了它的测试工具类，形成AppFoo↔PHPUnitFrameworkTestCase的双向持有 - 多个包都声明
"App\": "src/"→class_exists('AppUser', false)可能触发错误加载顺序，让两个本不该见面的类互相new对方实例 - 用
class_alias()注册别名后没清理旧映射 → 全局符号表里残留引用，GC 扫描时始终无法归零
确认是不是 GC 问题，别看 Composer 日志
Composer 输出里没有 GC 相关信息。composer install 结束后内存上涨，只说明你的应用代码开始执行了——此时才轮到 PHP GC 发挥作用。
真要验证，必须进运行时环境：
- 启用 GC 日志：
php -d zend.gc_debug=1 your-app.php，观察是否高频出现gc_collect_cycles() returned 0 - 临时关闭 GC：
gc_disable();+ 执行关键逻辑 +gc_collect_cycles();，对比耗时变化。若关闭后快很多，说明循环引用已堆积 - 用
xdebug_get_gcstats()（Xdebug 3.3+）查root_buffer_length，长期 > 10000 就得顺着引用链往下挖 - 别跑
composer validate或composer show—— 这些命令对循环引用完全无感
镜像和 GC 是两条平行线：一个管下载快不快，一个管内存收不收得回来。把网络卡顿当成 GC 问题，就像把硬盘灯狂闪当成 CPU 过载——现象相似，根源不同。排查时先锁死请求路径是否走对镜像，再进 PHP 进程看引用图，顺序错了，越查越偏。
