composer 2.x 全局换源命令必须严格使用 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，缺一不可：-g 确保全局生效，repo.packagist 是唯一合法键名，composer 是必需 type 值，url 必须 https 且末尾带 /；配置后需用 composer config -g repo.packagist 验证输出是否为完整 json 对象，否则无效。
composer config -g repo.packagist 命令必须带齐三个参数
这条命令不是“大概对就行”，漏掉任意一个，Composer 2.x 就会静默 fallback 到 https://packagist.org，不报错、不提示、也不警告。
-
-g不能省：缺了就只改当前项目composer.json，换目录或新开终端就失效 -
repo.packagist是唯一合法键名：写成repos.packagist（多一个 s）、packagist.org或大小写混用（如Repo.Packagist）都会写进无效字段，查不到也用不上 -
composer是必需的type值：不是注释，不是可选参数；漏掉它，Composer 直接忽略整条配置 -
https://mirrors.aliyun.com/composer/必须是 HTTPS 且末尾带/：少斜杠会拼出/composerpackages.json，返回 404；HTTP 地址在 Composer 2.5+ 中被强制拒绝
正确写法只有一种：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
验证是否真的生效，别信命令输出
执行完命令后，终端显示 “OK” 或没报错 ≠ 配置成功。真正判断依据只有一条：
运行 composer config -g repo.packagist，输出必须是完整 JSON 对象，形如：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
- 返回空、
null、报Key not found，说明根本没写进去 - 返回原始 URL 字符串（比如只有
"https://packagist.org"），说明没覆盖成功 - Windows 用户改完需重启终端，否则配置缓存不刷新
- CI 流水线里若用
sudo composer config -g，可能写进了root用户配置，但构建时用的是runner用户，读不到
全局配置在多用户环境（宝塔/Docker/CI）中常失效
全局配置写在 ~/.composer/config.json，但它只对当前 shell 用户生效。Web 服务、计划任务、CI 构建往往以不同用户身份运行，导致镜像“配了等于没配”。
- 宝塔默认用
www用户执行命令：需先确认用户，再运行sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - Docker 容器内若未指定用户，可能以
root运行，但容器外配的是宿主机普通用户 - GitHub Actions 默认用
runner用户，-g配的是该用户的 home 目录，不是 root - 更稳妥的做法是项目级配置：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g），它会自动写入当前项目的composer.json的repositories字段，Git 可追踪、所有环境行为一致
换源后仍卡在 “Loading composer repositories” 怎么办
不是镜像不可用，而是 Composer 还在读旧缓存或旧 composer.lock 文件里记录的官方源地址。
- 先清缓存：
composer clear-cache - 删掉项目下的
vendor/和composer.lock - 再执行
composer install -vvv，观察日志中是否出现mirrors.aliyun.com；如果仍有packagist.org，说明配置未生效，或项目级repositories字段覆盖了全局设置 - 注意：
composer update不会重新加载镜像配置——它只基于现有composer.lock解析依赖；要彻底走新镜像流程，必须删 lock 文件后重装
镜像只加速元数据拉取和 ZIP 下载，不解决 Resolving dependencies 卡顿问题。那部分慢，得查 PHP 内存限制、Xdebug 是否开启、composer.json 里版本约束是否太宽。
