composer下载卡在downloading的主因是zip包仍直连github.com，而非packagist元数据源；阿里云镜像仅代理元数据，不托管zip，需配合ghproxy、satis或清理composer.lock才能真正加速。
不能只配 packagist.org 元数据源就以为“加速完成”——composer install 卡在 Downloading，八成是因为 zip 包还在直连 github.com。国内网络环境下，GitHub 域名解析慢、TLS 握手超时、连接重置才是真瓶颈。
为什么配了阿里云镜像还是从 github.com 下载 zip？
因为 Composer 的镜像机制是“分层”的：packagist.org（或镜像）只提供元数据（包名、版本、依赖关系），而实际 zip 包仍默认走 GitHub。镜像源本身不托管 zip 文件，除非你用的是支持完整代理的私有仓库或特殊镜像服务。
常见错误现象：
-
composer install -vvv日志里反复出现Downloading https://api.github.com/...或Downloading https://codeload.github.com/... - 元数据加载飞快，但某个包卡在
Downloading30 秒以上 - 换源后
composer config -g repo.packagist显示正确，但速度毫无改善
解决思路不是换 packagist 镜像，而是绕过 GitHub 下载路径：
- 用
composer config -g github-protocols https强制走 HTTPS（避免 git 协议触发 SSH 认证或代理问题） - 在项目
composer.json中为特定包显式指定dist地址（适用于私有包或高频更新包） - 企业级方案：部署
satis或toran proxy，把 GitHub zip 缓存到内网；个人开发更推荐直接用ghproxy.com类型的反向代理
临时加 --repository 参数为何有时没效果？
--repository 只影响元数据获取环节，对已锁在 composer.lock 中的 dist URL 完全无效。一旦 lock 文件里记录的是 https://api.github.com/...，Composer 就会照单下载，无视任何镜像配置。
使用场景与限制：
- 仅对
composer install和composer update生效，composer require不识别该参数 - 必须写成
--repository=https://mirrors.aliyun.com/composer/，--repository-url是无效参数名 - 若
composer.lock已存在且含旧 dist URL，需先删 lock 文件再跑 install，否则加速不生效
验证是否真正起作用：执行 composer install -vvv | grep "Loading composer repositories"，输出应含你指定的镜像域名，而非 packagist.org。
composer create-project 拉骨架巨慢，怎么跳过 autoload 扫描？
这不是网络问题，是本地 PHP 解析开销。Composer 3.x+ 默认启用 classmap-authoritative 模式，create-project 内部调用 install 时会强制扫描整个 vendor/ 目录生成 classmap，Laravel 类项目常卡 1–2 分钟。
实操建议：
- 加
--no-install参数：如composer create-project laravel/laravel myapp --no-install，只解压骨架，不进 vendor、不生成 autoload - 后续按需执行
composer install --no-dev，此时可配合composer config authorative false关闭权威 classmap - 若项目含
post-create-project-cmd（如 Laravel 的key:generate），这些脚本不会运行，得手动补：php artisan key:generate
注意：--no-install 不影响 zip 下载，骨架文件结构完整，只是跳过依赖安装和自动加载器初始化。
真正卡住你的往往不是 packagist，而是 GitHub 的 zip 下载链路；composer.lock 里的 dist URL 是硬编码地址，换源命令无法覆盖它；autoload 扫描耗时远超网络下载——这些点不排查清楚，光改 repo.packagist 就只是自我安慰。
