直连 packagist.org 在国内不可达，因无 cdn、dns 解析指向境外、tls 握手超时且 composer 无重试机制；必须配置中文镜像并清缓存才生效。
composer install 卡在 Loading composer repositories，不是你网络差，是直连 packagist.org 在国内根本不可达——行业大牛用中文镜像，是因为他们早就不跟物理限制硬刚了。
为什么直连 packagist.org 必然失败
不是 Composer 慢，是网络层就断了：packagist.org 没有国内 CDN、DNS 解析常指向美国或新加坡 IP、TLS 握手在中间链路频繁超时，且 Composer 自身无重试机制。实测 curl -I https://packagist.org/packages.json 在多数办公网络下超时或卡 10 秒以上。这不是“偶尔不稳定”，而是常态。
镜像配置写错一个字符就等于没配
新版 Composer（≥ 2.2）对键名、type、URL 格式极其敏感，错一处就静默失效：
-
repo.packagist是单数，写成repos.packagist（多一个 s）→ 配置存进去了，但 Composer 完全不读 -
type值必须显式写composer，漏掉它 → 新版直接 fallback 到官方源，不报错也不提示 - URL 必须是
https://mirrors.aliyun.com/composer/，末尾斜杠/不可省；少斜杠会拼出/composerpackages.json→ 404 后静默回退 - 协议必须是 HTTPS：
http://地址在 Composer 2.x 中直接被拒绝，报Invalid repository type
全局配置 vs 项目级配置，哪个更可靠
全局配置看着省事，但在真实场景里经常被绕过：
- CI 流水线用的是
runner用户，宝塔后台用的是www用户，Docker 构建里甚至没有~/.composer目录 - 项目级配置写入
composer.json的repositories字段，可提交 Git，所有成员行为一致 - 执行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意没-g）会安全新增 packagist 子项，不覆盖已有私有源 - 但如果原
composer.json里"repositories": []（数组），该命令会失败；得先手动改成"repositories": {}（对象）
换镜像后还是卡？别查配置，先看实际请求发到哪了
现象是 Loading composer repositories 卡住，但 composer config -g repo.packagist 显示正确 ≠ 镜像真在用：
- 项目级
composer.json中的repositories优先级永远高于全局配置，且不报错 - 检查是否写了
"packagist.org": false或"packagist": false—— 这类语句会彻底关掉源 - 加
-vvv运行composer install，看日志里Downloading行实际连接的是哪个域名 - Linux/macOS 默认走 IPv6，但国内镜像站 IPv6 支持不全，fallback 前会卡几秒；加环境变量
COMPOSER_IPV4=1强制走 IPv4
composer clear-cache，否则旧缓存里的元数据仍会触发对 packagist.org 的请求——配置对了，但缓存没清，等于白配。
