全局配置必须严格执行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，缺-g、键名repo.packagist（非复数）、composer类型值或URL末尾/任一要素均静默失效，导致仍连接packagist.org。
composer config -g repo.packagist 必须带三个参数
这条命令不是“配个 URL 就完事”，缺任何一个都会静默失败——不报错，但 composer install 依然连 packagist.org。
正确写法只有一种：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
-
-g：必须加，否则改的是当前项目composer.json里的repositories字段，不是全局 -
repo.packagist：键名严格为单数、小写、无空格、无 s；写成repos.packagist或repository.packagist都无效 -
composer：这是type值，不是注释或可选参数；漏掉它，Composer 2.x 会直接 fallback 到官方源 -
https://mirrors.aliyun.com/composer/：协议必须是https://，末尾必须带/；少斜杠会拼出/packages.json导致 404
为什么配置了还是走 packagist.org？优先级和覆盖逻辑
Composer 的源选择有明确顺序：项目级 composer.json 中的 repositories > 全局配置 > 默认源。只要当前目录存在 composer.json 且含 repositories 字段（哪怕为空数组），全局镜像就完全失效。
验证方法很简单：
- 运行
composer config repo.packagist（不加-g）：如果输出 URL，说明项目级已覆盖；如果提示Key "repo.packagist" does not exist，才落到全局 - 检查
composer.json是否有"repositories": []或{"packagist.org": false}这类显式声明 - 临时绕过项目级配置：加
-n参数，比如composer install -n，此时强制读全局
Windows 和 Docker 环境下容易忽略的细节
Windows 用户执行完 composer config -g 后，终端不会自动刷新环境变量或配置缓存，必须关闭当前命令行窗口、重新打开再测试，否则 composer config -g repo.packagist 查不到新值。
Docker 或 CI/CD 构建中更常见坑：
- 用
sudo composer config -g写进了root用户的~/.composer/config.json，但构建实际跑在www-data或普通用户下，根本读不到 - 容器默认没挂载
~/.composer，每次启动都是干净状态，composer config -g的结果不持久；必须在Dockerfile的RUN阶段显式执行该命令 - GitHub Actions 等平台若缓存了
vendor/却没缓存~/.composer，会导致下次构建仍走慢源
验证是否真生效，别只看 config 输出
composer config -g repo.packagist 输出 JSON 只说明“写进去了”，不代表“用上了”。真正验证得看网络请求路径：
- 运行
composer clear-cache && composer require monolog/monolog -vvv - 观察日志里类似这样的行：
Downloading https://mirrors.aliyun.com/composer/packages.json - 如果看到的是
https://packagist.org/packages.json或https://repo.packagist.org/packages.json，说明镜像没生效 - 也可用
composer diagnose，重点看Repo packagist.org:后面是不是你设的镜像域名
最常被忽略的一点：镜像服务本身是否可用。阿里云、腾讯云偶尔同步延迟，华为云路径是 /repository/php 而非 /composer，写错地址或服务不可达时，composer install 会卡在 “Loading composer repositories” —— 这不是配置问题，是镜像链路断了。
