composer config -g repo.packagist 常无效是因为三个硬性条件缺一即静默失败：键名必须为单数小写 repo.packagist、中间必须显式写 type 值 composer、url 必须 https 且末尾带 /；验证需输出完整 json 对象。
全局配置只对当前用户生效，且只要项目里有 repositories 字段，它就完全不生效——不是优先级低，是压根不读。
为什么 composer config -g repo.packagist 经常没反应
这条命令看似简单，但三个硬性条件缺一即静默失败：
-
repo.packagist键名必须是单数、小写、无 s；写成repos.packagist或packagist.org都无效 - 中间的
composer是必填的type值，不是可选参数，也不是注释 - 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、或仍是 https://packagist.org，说明根本没落盘。
项目级 repositories 字段为什么总是赢
只要项目根目录下 composer.json 里定义了 repositories 字段（哪怕只是 {} 或 []），Composer 就彻底跳过全局配置，不合并、不 fallback。
- CI/CD 流水线（如 GitHub Actions）默认用
runner用户执行，而composer config -g很可能写进了你本地$USER的~/.composer/config.json，两者完全隔离 - 宝塔面板里 PHP 进程常以
www用户运行，你在终端用root配的镜像，它根本看不到 - Docker 容器未挂载宿主机
~/.composer目录时，容器内永远是默认源 - 某些 Laravel 脚手架模板自带硬编码源，
composer create-project第一次就会绕过全局镜像直连 packagist.org
真正可靠的写法：进项目根目录，运行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉 -g）。它会自动把镜像写入 composer.json 的 repositories 对象中，key 固定为 "packagist"。
换源后还是卡在 Loading composer repositories 怎么办
这不是镜像没配对，而是 Composer 在读旧缓存和旧锁文件：
- 必须执行
composer clear-cache，否则本地缓存仍指向旧地址 - 必须删掉项目下的
vendor/和composer.lock，否则composer install仍按旧 lock 文件解析包地址 - 运行
composer install -vvv，观察日志里是否出现mirrors.aliyun.com或mirro（Composer 2.x 日志常截断） - 如果项目已有
"repositories": []（数组），composer config命令会直接报错；得先手动改成"repositories": {}（对象）再重试
镜像只管元数据（packages.json、p2/xxx.json）下载路径，ZIP 包的实际地址由 composer.lock 或包自身定义，镜像不代理也不改写——这点最容易被忽略。
