composer config -g repo.packagist 命令总不生效是因为必须同时满足三个硬性条件：键名严格为单数 repo.packagist、中间参数必须显式写出 composer（type 值）、URL 必须 HTTPS 且末尾带 /；任一缺失均静默失败，验证需执行该命令并输出完整 JSON 对象。
composer config -g repo.packagist 命令为什么总不生效
不是网络问题，也不是权限不足，而是三个硬性条件缺一不可：repo.packagist（单数，不能是repos.packagist）、中间的composer（必须作为type值显式写出）、URL末尾必须带/。漏掉任意一个，命令会静默执行成功但实际没写入配置。
验证是否真生效，别只看命令有没有报错，直接运行：composer config -g repo.packagist
输出必须是类似这样的完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
如果返回空、null、Key does not exist，或者还是https://packagist.org，说明根本没写进去。
换源后 composer install 仍卡在 Downloading
镜像只加速下载环节，但 Composer 默认会优先读取本地缓存和 composer.lock 里记录的老地址——哪怕你刚配好新镜像，它还在反复尝试连 packagist.org，卡在 DNS 或 TLS 握手阶段。
必须清干净三样东西：
-
composer clear-cache（注意不是composer cache-clear，后者已废弃） - 删掉项目根目录下的
vendor/目录 - 删掉
composer.lock
再跑 composer install -vvv | grep -i "mirrors-aliyun"，看到日志里出现 https---mirrors-aliyun-com-composer 这类路径才算真正走镜像。
全局配置 vs 项目级配置：哪个才真正可靠
你在终端配了 composer config -g，但宝塔后台、GitHub Actions、Docker 容器里照样卡住——因为它们用的是 www、runner 或其他用户，根本读不到你的 ~/.composer/config.json。
团队协作或 CI 场景下，项目级配置才是真实解法：
- 先进入项目根目录（确保有
composer.json） - 运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g） - 这条命令会自动在
composer.json的repositories字段里安全写入，不会覆盖已有私有源 - 如果
composer.json里"repositories"是数组（比如已定义私有包），命令会失败；需先手动改成"repositories": {}再重试
进度条不动？先确认 PHP CLI 环境是否正常
尤其在宝塔、Docker 或某些共享主机上，Composer 根本启动不了，更别说走镜像了。常见拦路虎是 PHP 禁用了关键函数：
-
proc_open被禁用 → Composer 启动即崩溃 -
putenv被禁用 → 配置无法加载 -
openssl扩展未启用 → HTTPS 请求反复失败重试，表现就是“卡住”
验证方式：php -m | grep -E "openssl|tokenizer"php -r "echo proc_open('echo 1', [], $p) ? 'ok' : 'fail';"
环境不稳，换镜像只是给故障加速。
