Composer config -g repo.packagist 命令静默失败，因其必须同时满足键名repo.packagist（单数）、type值为composer、URL为HTTPS且末尾带/，缺一即回退官方源；验证需输出完整JSON对象。
composer config -g repo.packagist 命令为什么总没反应
它不是“没反应”，是静默失败——漏掉任意一个硬性条件，Composer 就当配置不存在，直接回退到 https://packagist.org，连 warning 都不报。
必须同时满足这三点：
-
repo.packagist是唯一合法键名（注意是repo单数，写成repos.packagist、packagist.org全部无效） - 第二个参数
composer是type值，小写，不可省略，也不能写成composer.org - URL 必须是 HTTPS 且末尾带
/：比如https://mirrors.aliyun.com/composer/✅，少斜杠会拼出/composerpackages.json导致 404
验证是否真写进去了？别信终端没报错，直接运行：composer config -g repo.packagist。输出必须是完整 JSON，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null 或提示 Key does not exist，说明根本没写成功。
项目级配置比全局更可靠，尤其在 CI 和容器环境
全局配置（-g）只影响当前用户的 ~/.composer/config.json，但在宝塔、GitHub Actions、Docker 容器或 Vagrant 中，PHP 进程往往以 www、runner 或其他用户身份运行，压根读不到你的配置。
推荐做法：进项目根目录（含 composer.json），执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
这条命令会自动在 composer.json 顶层写入 "repositories" 字段，key 固定为 "packagist"，不会覆盖已有私有源。但要注意：
- 如果
composer.json里已有"repositories": []（数组形式），命令会静默失败；需先手动改成"repositories": {}（空对象）再重试 - 改完必须删掉
vendor/和composer.lock，再跑composer install（不是update） -
repositories字段一旦存在，就会完全屏蔽全局配置，优先级更高
换源后仍卡在 “Loading composer repositories” 怎么快速定位
这不是镜像地址问题，而是请求根本没发到你配的地址——Composer 还在用缓存或旧元数据。
排查顺序很关键：
- 先运行
composer diagnose，看Repo.packagist.org行是否显示为你配的镜像 URL - 再执行
composer clear-cache清掉本地缓存 - 如果还卡，检查
composer.lock文件里是否还锁着packagist.org的 URL；有就删掉它和vendor/，重新composer install
注意：composer update 不会刷新镜像源本身，它只更新依赖版本；源地址变更必须靠 clear-cache + 重装触发。
parallel-downloads=10 是提速刚需，但只对 install 有效
Composer 2.2+ 默认并发数是 3，等于没开并行。不调这个值，哪怕镜像再快，下载仍是瓶颈。
全局启用：
composer config -g parallel-downloads 10
CI 脚本中建议显式带上：
composer install --prefer-dist --no-dev
别盲目冲到 20：企业网络或低配 CI 容易触发 file_put_contents(): failed to open stream（临时文件竞争），降到 6–8 更稳。
最后提醒一句：镜像只加速包下载，不解决 Resolving dependencies 卡住的问题。那通常是 composer.lock 缺失、minimum-stability 设为 dev，或引用了不可达私有仓库导致的——这些和镜像无关，得另查。
