{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}：该命令直接读取全局配置文件中 repo.packagist 字段，输出必须为合法 JSON 对象且 url 以 https:// 开头、结尾带 /。
composer config -g repo.packagist 输出的是什么
这条命令直接读取全局配置文件 ~/.composer/config.json 中的 repo.packagist 字段，输出内容必须是合法 JSON 对象，且 url 值要以 https:// 开头、结尾带 /。常见错误输出包括：
-
null或空行：说明根本没写入配置 -
{"type": "composer", "url": "https://packagist.org"}：未换源或被覆盖 -
{"type": "composer", "url": "https://mirrors.aliyun.com/composer"}（缺末尾/）：URL 拼接失败，实际请求会 404
正确示例应为：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
为什么 composer diagnose 的 Repo 行更可信
composer diagnose 不只是读配置，它会模拟运行时行为，主动解析并报告当前“准备连接”的地址。关键看这行输出：
Repo packagist.org: https://mirrors.aliyun.com/composer/
如果这里仍是 https://packagist.org，哪怕 composer config -g repo.packagist 显示了镜像地址，也说明项目级 repositories 字段已覆盖全局设置。此时进项目目录执行：
composer config repo.packagist
若有输出，就坐实了覆盖；若提示 Key "repo.packagist" does not exist，才继续查全局或环境变量。
如何用 -vvv 日志确认真实 HTTPS 请求地址
配置可能“写了”，但不等于“走了”。真正起作用的是 Composer 实际发起的 HTTP(S) 请求。验证必须触发一次真实网络操作：
- 先清缓存：
composer clear-cache - 再执行：
composer require monolog/monolog -vvv 2>&1 | grep "GET https"
重点看第一行匹配到的 GET https://... —— 它才是真实请求地址。如果出现 GET https://packagist.org/packages.json，说明镜像完全没生效，和 DNS、代理、网络延迟都无关，纯属配置未命中。
环境变量和项目级配置的优先级陷阱
Composer 查源顺序是：环境变量 > 项目级 repositories > 全局 config.json。容易被忽略的点：
-
COMPOSER_REPO_PACKAGIST环境变量存在时，会直接跳过所有配置文件 - 项目
composer.json中的repositories如果包含"packagist": false或自定义packagist条目，会彻底屏蔽全局镜像 -
composer config -v repo.packagist可显示该键值来自global还是local，甚至具体路径，比盲猜可靠得多
HTTPS 地址是否生效，从来不是“配了没”，而是“谁在管、谁在读、谁真发了请求”。日志里那个 GET https:// 才是唯一不可辩驳的事实。
