Composer卡在Downloading是因为未正确配置镜像：必须严格执行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，键名repo.packagist（单数）、type值composer、URL为HTTPS且末尾带/，缺一即静默回退至packagist.org。
Composer 卡在 Downloading...，不是你网络差，是默认还在连 packagist.org —— 换镜像不是“试试看”，是必须做的第一步。
composer config -g repo.packagist 命令为什么总不生效
90% 的失败不是网络问题，而是命令写错三个硬性条件，Composer 会静默 fallback 回官方源，不报错也不提示：
-
repo.packagist键名不能多一个s（repos.packagist❌） - 第二个参数必须是
composer（这是 type 声明，漏掉就当没配） - URL 必须是 HTTPS 且末尾带
/（https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌）
验证是否真写进去了：运行 composer config -g repo.packagist。输出必须是类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 的完整 JSON；如果为空、null、或只返回 https://packagist.org，说明配置根本没生效。
宝塔、CI 或 Docker 里全局镜像为啥还是慢
全局配置写在当前用户的 ~/.composer/config.json，但宝塔后台、GitHub Actions runner、Docker 容器里的 PHP 进程往往以 www、runner 或非 root 用户身份运行，根本读不到你本地的配置。
立即学习“PHP免费学习笔记（深入）”；
解决方法很直接：
- 查清实际执行用户：在宝塔终端里运行
whoami或id -u - 用对应用户重配：比如
sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - CI 脚本中别依赖全局配置，改用临时参数更可靠：
composer install --repository=https://mirrors.tuna.tsinghua.edu.cn/composer/
项目级配置怎么安全加镜像不丢私有源
执行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加 -g）时，Composer 会尝试向 composer.json 的 repositories 字段追加条目——但前提是该字段已存在且格式正确。
如果你的项目已有私有 Git 源或 Satis 源，更稳妥的做法是手动编辑 composer.json：
- 确保顶层有
"packagist.org": false（不是放在repositories里面） - 在
"repositories"数组里显式添加："packagist": {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} - 改完立刻删掉
vendor/和composer.lock，再跑composer install，否则旧 lock 文件里的哈希和镜像元数据不匹配，会报hash does not match
怎么确认 Composer 真正在用镜像
光看 composer config -g repo.packagist 输出 URL 没用，得看到实际请求打到镜像域名才算数。
最直接的验证方式：
- 运行
composer show monolog/monolog -vvv 2>&1 | grep "Downloading" - 日志里必须出现
mirrors.aliyun.com、mirrors.tuna.tsinghua.edu.cn等镜像域名 - 如果看到
packagist.org或repo.packagist.org，说明 fallback 已触发，配置失效
注意：换源后首次安装，务必先 composer clear-cache，否则旧缓存里的元数据会强制 Composer 尝试从旧地址校验，卡在 TLS 握手或 DNS 查询阶段，根本发不出请求。
