直接查当前生效镜像地址应运行composer config repo.packagist.org，它按优先级自动合并项目级与全局配置并忽略无效旧键，输出JSON即实际请求源，报错则走默认官方源；加-v可定位配置文件位置。
直接查当前生效的镜像地址：composer config repo.packagist.org
这条命令输出的就是此刻 Composer 实际请求走的源，不看配置写了啥，只看“真正在用啥”。它按优先级自动合并项目级、全局配置，跳过无效或旧键名，结果最贴近真实行为。
- 如果输出类似
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}，说明正在用这个镜像 - 如果报错
Could not find repository 'packagist.org'，说明没配任何镜像，走默认官方源https://packagist.org - 加
-v参数（composer config -v repo.packagist.org）能额外看到这行配置定义在哪个文件里，方便定位是项目composer.json还是全局~/.composer/config.json
为什么 composer config -g repo.packagist 经常不准
因为 repo.packagist 是旧键名，Composer 2.2+ 已统一为 repo.packagist.org；而且 -g 只读全局配置，完全忽略项目级 repositories 段——而后者优先级更高，实际覆盖了全局设置。
- 常见误判：运行
composer config -g repo.packagist返回阿里云地址，但composer update却卡住——大概率是项目composer.json里写了另一个失效镜像，把它盖掉了 -
composer config -g repos.packagist（复数repos）在部分老版本里还能用，但在新版本中已被弃用，不推荐依赖 - 真正起作用的键永远是
repo.packagist.org，无论写在哪儿
镜像配置生效但请求失败？重点检查三件事
Composer 不校验 URL 是否可达，配置写错也不会报错，直到 update 或 install 时才暴露问题。光看 config 输出还不够。
- 必须执行
composer clear-cache，否则仍用旧源缓存的packages.json元数据 - 用
curl -I https://mirrors.aliyun.com/composer/（注意末尾/）确认返回200或302；少个/可能返回404导致降级回官方源 - 检查项目
composer.json中是否有"repositories"段，哪怕只有一行，也会屏蔽全局镜像——临时注释掉再试，就能验证是不是它在捣鬼
从 lock 文件反查包的真实来源
如果想确认某个具体包是从哪个地址拉下来的，composer config 无能为力，得看 composer.lock 里的记录，它才是最终权威。
- 对 dist 安装的包，查
dist.url字段，比如"https://api.github.com/repos/monolog/monolog/zipball/..." - 对 source 安装的包，查
source.url，通常是 Git 地址，如"https://github.com/Seldaek/monolog.git" -
composer show -v vendor/package也能显示这些字段，但它可能已被镜像重写；composer.lock是原始快照，更可信
实际改源之后，最容易被忽略的是缓存和项目级配置的双重干扰。别只盯着 config 输出看，一定要 clear-cache + curl 测通 + lock 文件核对三步并行。
