Composer元数据拉取慢本质是直连packagist.org的p2/请求卡在DNS、TLS或首字节延迟，并非下载慢；必须用composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（含type值和末尾/）配置镜像，再通过composer install -vvv | grep "mirrors.aliyun"验证日志是否真实走镜像。
Composer元数据拉取慢，本质是 packagist.org 的 p2/ 目录（如 p2/laravel/framework.json）请求卡在 DNS、TLS 或首字节延迟上，不是“下载慢”，而是“连不上”。换镜像源是必须动作，但只改 URL 不等于生效。
composer config -g repo.packagist 必须带 type 参数
很多用户执行 composer config -g repo.packagist https://mirrors.aliyun.com/composer/，看似成功，实际配置静默无效。Composer 2.x 要求该配置项必须是完整对象：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。
- 正确命令是：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意中间的composer是type值，不能省） - URL 末尾必须有
/，少一个斜杠会导致路径拼接错误，例如变成https://mirrors.aliyun.com/composerp2/xxx.json，直接 404 - 验证是否写入成功：
composer config -g repo.packagist输出必须是完整 JSON 对象，不是纯字符串
项目级配置比全局更可靠，尤其 CI/CD 场景
全局配置在 Docker、多用户或不同 PHP 版本环境下容易被覆盖。CI 脚本里用 sudo composer config -g 写进 root 配置，但 runner 是普通用户，就读不到。
- 推荐进项目根目录执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g） - 该命令会自动向
composer.json的repositories数组追加 packagist 条目，不破坏已有私有源 - Git 提交后，新人拉代码即用；Docker 构建时也无需额外配置命令
- 若
composer.json已有空"repositories": {}，手动编辑极易漏逗号或引号，务必用命令操作
确认是否真走镜像：别信 config，要看 -vvv 日志
composer config -g repo.packagist 输出正常 ≠ 实际请求走镜像。缓存没清、旧 composer.lock 残留、DNS 缓存都可能让请求仍发往 packagist.org。
- 必须加
-vvv运行一次安装：composer install -vvv 2>&1 | grep "mirrors.aliyun" - 日志里看到类似
GET https://mirrors.aliyun.com/composer/p2/laravel/framework.json才算真正生效 - 如果只看到
GET https://packagist.org/p2/或报Connection timed out，说明配置没起作用或被覆盖 - 旧版 Composer 1.x 不支持
repo.packagist键名，得用：composer config -g repos.packagist '{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}'
Resolving dependencies 卡住？那跟镜像无关
换了镜像还卡在 Resolving dependencies 阶段，说明问题不在网络，而在本地环境。这个阶段完全不发 HTTP 请求，纯 PHP 计算。
- Xdebug 启用中会让解析慢 5–10 倍——临时禁用：
php -d xdebug.mode=off $(which composer) update -
memory_limit过低（如 128M）会导致依赖图解析失败重试——临时提高：COMPOSER_MEMORY_LIMIT=-1 composer update -
platform配置与实际 PHP 版本不匹配（如"php": "7.4"却在 PHP 8.2 上运行），触发降级查找逻辑 -
composer.lock残留已下线包的引用，导致回退搜索——删掉vendor/和composer.lock，再用composer install --no-cache
镜像只解决元数据和包下载的网络瓶颈，而 Resolving dependencies 是纯 CPU+内存密集型任务，最容易被忽略的是 Xdebug 和 memory_limit —— 这两个点不排查，换十次镜像也没用。
