composer config --list 显示的是合并后生效配置而非原始文件内容，它叠加命令行、环境变量、项目及全局配置四层，但不标注来源、不显示默认值或被覆盖项；composer diagnose 才真实反映运行时请求地址，是验证镜像是否生效的唯一可靠依据。
composer config --list 显示的是“合并后”的配置，不是原始配置文件内容
它把命令行参数、环境变量、项目 composer.json、全局 config.json 四层叠在一起，输出最终生效值，但不标注来源、不显示默认值、也不体现被覆盖的旧项。比如你没设过 process-timeout，它就不会出现在 --list 输出里，尽管实际运行时默认是 300。
常见误判点：
- 看到
repositories.packagist.org.url有值，就以为镜像一定生效——但COMPOSER_REPO_PACKAGIST环境变量可能早已把它顶掉 - 用
grep repositories扫出来的结果里混着repositories.packagist和repositories.packagist.org，两者独立存在、可能值还不一样 - 输出中带
(global)标记的才是来自全局配置；没标记的，可能是项目级改写，也可能是环境变量注入
想确认镜像到底走哪，别只看 config，得看 diagnose 的真实请求地址
composer diagnose 会发起一次轻量 HTTP 请求，然后在 “Repo packagist.org” 行直接告诉你 Composer 实际连的是哪个 URL。这才是 install/update 时真正打出去的地址。
这个结果比任何 config 命令都准，因为它绕过了所有静态配置解析逻辑，直击运行时行为：
- 如果
diagnose显示https://mirrors.tuna.tsinghua.edu.cn/composer/，那当前就是走清华源 - 如果显示
https://packagist.org，说明镜像没生效，哪怕config -g repo.packagist返回了阿里云地址 - 出现
Could not resolve host或SSL certificate problem，说明镜像地址本身不可达，不是配置没读到
dump-autoload 和镜像无关，别指望它刷新源配置
dump-autoload 只负责重新生成自动加载映射（vendor/autoload.php），完全不触碰仓库配置、不清理缓存、也不重读 composer.json 里的 repositories 段。
换镜像后必须手动执行的步骤只有两个：
-
composer clear-cache：否则旧包元数据仍从本地缓存读取，可能装错版本 -
composer update或composer install：触发真实依赖解析和下载，才能验证镜像是否真被使用
顺带一提：composer dump-autoload --optimize 会生成更紧凑的 autoload 文件，但它对镜像切换毫无影响。
查镜像配置要分三路验证，漏一路就可能误判
Composer 镜像控制字段不止一个，且新旧键名并存，必须同时检查：
-
composer config -g repo.packagist：Composer 2.2+ 推荐键，优先级最高 -
composer config -g repositories.packagist.org.url：v2 标准路径，多数一键脚本写这里 -
composer config -g repositories.packagist.url：旧版键名，老项目或迁移残留常留这儿
只要其中任意一个返回非空 JSON，镜像就已配置；但如果 diagnose 显示的 URL 和它们不一致，就得立刻检查 COMPOSER_REPO_PACKAGIST 环境变量——它不显现在任何 config 命令输出里，但会无声覆盖所有配置。
