必须运行composer config -g repo.packagist，输出为空或报错“Key does not exist”才表示清空成功；若输出JSON或URL则镜像仍存在，还需检查repos.packagist、项目级repositories及环境变量。
怎么验证 composer config -g repo.packagist 已清空镜像设置
如果执行过 composer config -g --unset repos.packagist 或手动删了全局配置，不能只看命令没报错就认为还原成功。Composer 会 fallback 到默认源，但残留的自定义配置可能仍被读取。
真正有效的验证方式是直接查当前生效的源地址：
- 运行
composer config -g repo.packagist—— 如果输出为空，说明该键已删除；如果输出一个 URL（比如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}），说明镜像还挂着 - 更可靠的是查完整配置：运行
composer config -g，搜索repos或packagist字段，确认里面没有非默认的url值 - 注意：有些镜像配置写在
repos.packagist，有些写在repositories数组里，两者都要检查
为什么 composer clear-cache 不能证明镜像已还原
缓存清理只是删掉本地下载过的包文件和元数据，跟源地址配置完全无关。即使你刚执行完 composer clear-cache，只要 repo.packagist 还指向镜像站，后续 composer install 依然会从镜像拉包。
常见误判场景：
- 看到
Clearing cache (cache-dir): ...就以为“恢复出厂”了 - 改完配置没重启终端，导致某些 shell 环境变量（如
COMPOSER_HOME）仍指向旧配置路径 - 项目根目录下有
composer.json里的repositories覆盖了全局设置，你以为全局还原了，实际项目级镜像还在生效
用 composer diagnose 快速暴露配置冲突
这个命令不光检查网络连通性，还会扫描配置合理性。当镜像未彻底还原时，它常给出明确提示：
- 如果看到类似
Warning: The configured repository 'packagist' is not the default one. This may lead to unexpected behavior.，说明仍有自定义源 - 如果输出
OK且没有 warning 关于repository，基本可确认回归默认行为 - 注意：它不会告诉你具体哪一行配置有问题，所以仍要配合
composer config -g手动核对
真实安装时怎么看请求发到了哪个源
最硬的证据，是让 Composer 把 HTTP 请求路径打出来：
- 加
-v参数重装一个包：composer require monolog/monolog -v - 观察日志里类似
Downloading https://repo.packagist.org/packages.json的行 —— 如果域名是repo.packagist.org，说明已走官方源；如果是mirrors.aliyun.com或packagist.phpcomposer.com，说明镜像还在生效 - 注意：首次安装可能命中本地缓存，看不出真实请求。可先
composer clear-cache再试，或换一个从未装过的包（如composer require phpunit/phpunit）
配置还原不是“执行一个命令就结束”的事，关键在验证请求出口是否真的回到了 repo.packagist.org。很多人卡在以为删了配置就完了，结果 repositories 数组里还埋着一条 alias，或者项目级配置偷偷覆盖了全局。
