最直接检查方式是运行 composer config -g repos.packagist，输出非 {"type": "composer", "url": "https://packagist.org"} 即表示启用了镜像；若报错 key 不存在，需检查 repos.packagist.org；项目级配置需进目录执行不带 -g 的命令；composer diagnose 和 -v 日志可验证实际生效情况。
composer config -g repos.packagist 是最直接的检查方式
全局配置里 repos.packagist 的值，就是当前生效的 Packagist 镜像地址。它优先级高于项目级配置，且 Composer 7+ 默认会读取这个字段来决定源站。
- 运行
composer config -g repos.packagist，输出非{"type": "composer", "url": "https://packagist.org"}就说明用了镜像 - 如果报错
Key repos.packagist does not exist，不代表没镜像——可能镜像通过composer config -g repos.packagist.org单独配置（旧版常见） - 注意：Composer 2.2+ 开始支持
packagist.org作为 repo key 名，和旧版packagist并存，两者互不影响，需分别检查
项目级镜像常被忽略，得进项目目录再查
项目根目录下的 composer.json 或 composer.lock 附近若有自定义 repo，会覆盖全局设置。尤其团队协作时，容易误以为“全局配了就全项目生效”。
- 先进入项目目录，再执行
composer config repos.packagist（不带-g） - 若返回空，再查
composer config repos.packagist.org，有些脚本生成的配置用的是后者 - 更彻底的方式是看
composer config --list | grep repos，但要注意输出里带(global)和不带的区别 - 项目级配置中如果写了
"packagist": false，那所有 packagist 请求都会被禁用——此时即使全局有镜像也完全不走
composer diagnose 能暴露隐性冲突
composer diagnose 不只检查权限和网络，还会验证 repo 配置是否合法、是否相互覆盖，比如同时存在两个 packagist 类型 repo 会导致行为不可预测。
- 运行
composer diagnose，重点看 “Repo settings” 段落里的提示 - 如果出现
WARNING提到multiple packagist repositories defined，说明有重复或冲突配置，必须手动删掉一个 - 某些国内镜像脚本（如腾讯云、阿里云一键配置）会悄悄写入
packagist.phpcomposer.com这类已下线地址，diagnose会报Could not resolve host，但不会直接告诉你来源 - 该命令不修改任何配置，纯只读检测，适合 CI 环境做前置校验
镜像实际生效与否，得看 install/update 时的请求日志
配置写了 ≠ 生效了。Composer 会在下载包时按优先级选择 repo，而真实请求地址藏在 verbose 日志里。
- 加
-v参数重试一次安装：composer require monolog/monolog -v - 在输出中搜索
Downloading https://，看域名是不是你配的镜像地址（如mirrors.tencent.com） - 如果看到
https://packagist.org，说明配置未命中——常见原因是 repo key 写错、JSON 格式损坏、或被COMPOSER_REPO_PACKAGIST环境变量覆盖 - 环境变量优先级最高，运行
env | grep COMPOSER_REPO可快速排查
config 输出，得让 Composer 自己说出来——看 diagnose 的警告，再盯住 -v 下的真实请求。 
