验证composer中文镜像是否生效，必须运行composer config -g repo.packagist并确认输出为完整json对象如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；若返回空、null、报错或仍为packagist.org，则配置未写入，常见原因是键名误写为repos.packagist、漏掉composer type值或url末尾缺斜杠。
运行 composer config -g repo.packagist 看输出是否为完整 JSON
这是最直接的验证方式，但很多人只扫一眼就以为配好了。真正有效的输出必须是类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 的完整 JSON 对象。如果返回空、null、Key "repo.packagist" does not exist 或仍是 https://packagist.org，说明配置根本没写进去。
常见失效原因：repo.packagist 写成 repos.packagist（多一个 s）、漏掉中间的 composer type 值、URL 少了末尾斜杠 / —— 这三处任一出错，Composer 都不报错，只静默 fallback 回官方源。
加 -vvv 跑 composer install 查日志里实际请求的域名
光看 config 输出还不够，得确认命令执行时真走的是镜像。运行 composer install -vvv 2>&1 | grep "GET\|Downloading"，重点找类似 GET https://mirrors.aliyun.com/composer/p2/... 或 Downloading https://mirrors.tuna.tsinghua.edu.cn/composer/packages.json 的日志行。
如果看到的是 packagist.org 或 packages.json 请求卡在超时/403，说明镜像没生效。注意：日志里出现 packages.json 是关键信号，它是依赖解析的起点，这一步没走镜像，后面全白搭。
-
composer install -vvv必须在项目根目录下执行，否则可能读到项目级配置覆盖了全局 - 若项目
composer.json里已有"repositories"字段，它会完全屏蔽全局配置，此时日志显示的一定是该字段里的 URL
检查实际执行用户是否与配置用户一致
在宝塔、CI 或 Docker 中，composer config -g 配的是当前用户的 ~/.composer/config.json，但实际跑命令的可能是 www、runner 或 www-data 用户。你用 root 配了，不代表 CI 流水线能读到。
验证方法：在对应环境里先执行 whoami 确认用户，再切过去查配置：sudo -u www composer config -g repo.packagist。如果返回空，说明镜像没配到那个用户下。
CI 脚本中更稳妥的做法是临时指定源：composer install --repository-url=https://mirrors.aliyun.com/composer/，绕过全局配置依赖。
别忽略 composer clear-cache 和锁文件兼容性
换源后首次安装失败，大概率不是镜像问题，而是缓存或 lock 文件残留。旧 composer.lock 里记录的是 packagist.org 的包哈希，和镜像元数据不匹配，会导致校验失败。
建议操作顺序：
- 执行
composer clear-cache清掉本地缓存（尤其~/.composer/cache） - 删掉
vendor/和composer.lock - 再跑
composer install
如果跳过这步，即使镜像已生效，也可能卡在 hash 校验环节，误判为“镜像没用”。
