composer global config --list --verbose第一行Loaded config file:显示的路径才是Composer当前实际加载的全局配置文件，composer config -g仅显示历史写入内容，不反映真实生效路径。
composer global config --list --verbose 才是真实加载路径
执行这条命令，第一行 Loaded config file: 显示的路径，才是 Composer 当前实际读取的全局配置文件。别信 composer config -g 的输出，它只显示“你写过什么”，不反映“正在用哪个文件”。常见失效场景包括：
- 用
sudo composer global config把配置写进了/root/.composer/config.json，但你是普通用户，根本读不到 -
COMPOSER_HOME环境变量里写了~/my-composer或$HOME/.composer，没展开成绝对路径，Composer 会静默 fallback 到默认位置 - Windows 下 Git Bash 里设了
%COMPOSER_HOME%，但大小写写成composer_home—— 它严格区分大小写，直接忽略
composer config -g repo.packagist 必须输出合法 JSON
这是验证镜像源是否写入成功的唯一可靠方式。正确输出只能是形如：
{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}
注意三点：
-
type字段必须显式存在且值为"composer"，漏掉就回退官方源 -
url必须是 HTTPS 协议、以/结尾，少一个斜杠会导致后续请求拼出/composerpackages.json这种错误路径 - 整个内容必须是合法 JSON：双引号、冒号、逗号、花括号一个不能少；输出
null、空行、"https://packagist.org"或{}都代表失败
composer diagnose 显示的 “Repo packagist.org:” 行才是真实生效源
composer config -g repo.packagist 告诉你“存了什么”，composer diagnose 才告诉你“正在用什么”。重点看这行输出：
Repo packagist.org: https://mirrors.aliyun.com/composer/
如果这里还是 https://packagist.org 或 https://repo.packagist.org，说明配置被覆盖了。最常见原因是：
- 项目根目录的
composer.json里有"repositories"字段，哪怕只写了{"packagist.org": false}，也会让全局镜像完全失效 - 环境变量
COMPOSER_REPO_PACKAGIST被设为原始地址，优先级高于配置文件 - 用了
composer create-project --repository-url=...，该参数临时覆盖所有配置
composer clear-cache && composer require -vvv 看真实请求域名
缓存不清，换源等于白换。Composer 会复用旧的 packages.json 快照，导致 install 时仍连官方源，甚至卡在 Loading composer repositories。验证必须按顺序执行：
- 先运行
composer clear-cache（不是“建议”，是硬性前置） - 再执行
composer require monolog/monolog -vvv 2>&1 | grep "Downloading" - 日志中必须出现镜像域名，例如
Downloading https://mirrors.aliyun.com/composer/p2/monolog/monolog.json
如果看到 packagist.org 或 repo.packagist.org 的请求，说明镜像配置被绕过了——这时候回头查 composer.json 里的 repositories 字段，比重配一遍更有效。
