验证镜像是否写入全局配置的最快方式是运行composer config -g repo.packagist：输出{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}表示成功；为空、报错或显示https://packagist.org均说明未生效。
composer config -g repo.packagist 输出是否为空或错误
这是验证镜像是否写入全局配置的最快方式。它直接读取 ~/.composer/config.json，不依赖缓存、网络或项目上下文。
运行：composer config -g repo.packagist
- 输出类似
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}→ 镜像已写入且键名正确 - 输出为空或报错
Key 'repo.packagist' does not exist→ 没配置，或字段名拼错（如写成repos.packagist、repository.packagist、repo.packagist.org） - 输出
{"type": "composer", "url": "https://packagist.org"}→ 配了但值没改，仍走官方源
注意：Windows PowerShell 中 URL 可能被误解析，建议加引号：composer config -g "repo.packagist"
curl -I 测试镜像地址是否真实可达
别信 composer diagnose，它硬编码只连 https://packagist.org，跟你配的镜像无关。
真正要测的是你写的那个 URL 能不能响应：
- 用
curl -I https://mirrors.aliyun.com/composer/packages.json→ 应返回HTTP/2 200 - 若 SSL 报错，加
-k绕过证书校验：curl -kI https://mirrors.aliyun.com/composer/packages.json - 若超时或 404，先查 DNS：
nslookup mirrors.aliyun.com；再换源或换网络，比调 Composer 配置更有效 - 某些镜像（如阿里云）要求末尾带
/，写成https://mirrors.aliyun.com/composer/才稳定
composer show -p | head -5 看实际请求域名
composer show -p 是唯一会发起真实 HTTP 请求并打印日志的轻量命令，它绕过了 diagnose 的限制，也避开了项目级 repositories 字段的干扰（只要没在 composer.json 里定义，就走全局配置）。
- 运行：
composer show -p | head -5 - 观察输出中是否有类似
Downloading https://mirrors.aliyun.com/composer/packages.json的行 - 如果出现
repo.packagist.org或github.com→ 镜像没真正生效 - 该命令不下载 zip 包，速度快，适合 CI 脚本中快速验证
清缓存 + -vvv 日志确认最终行为
改完配置后 composer install 还走老地址？90% 是本地元数据缓存没刷新。Composer 不会自动感知配置变更。
- 必须执行：
composer clear-cache - 再用详细日志跑一次：
composer -vvv require monolog/monolog - 在日志中搜索
GET https://，找到Loading composer repositories那行的完整 URL —— 这才是真实发起的请求地址 - 如果 URL 对了但卡住，说明网络或镜像服务问题；如果 URL 仍是官方地址，回头检查
composer config -g repo.packagist输出 - 某些环境（如 Jenkins 构建节点）可能设置了
HTTP_PROXY，会强制走代理绕过镜像，临时取消：unset HTTP_PROXY HTTPS_PROXY
镜像配置本身只是一行命令的事，难的是确认它在真实请求链路中没被覆盖、没被忽略、没被网络层劫持。
