composer config -g --list 仅显示手动设置的全局配置项，不显示默认值或未设置项；例如有 http-proxy 而无 https-proxy，说明后者未配置，这是代理失效的最常见原因。
composer config -g --list 能看到什么
这条命令输出全局配置，但只显示你手动写入的字段。如果看到 http-proxy 却没看到 https-proxy，说明 HTTPS 代理根本没设——这是最常见失效原因。输出里若出现 HTTP proxy: [none] 或 HTTPS proxy: [none]，代表对应字段为空或未加载。
为什么 composer diagnose 不够用
composer diagnose 只校验配置语法和本地状态，不发真实 HTTPS 请求。它可能显示 OK，但实际 composer install 仍卡在 Loading composer repositories。真正验证代理是否“通”，得触发 Packagist 的元数据请求：
-
composer global status：返回OK表示 HTTPS 代理可转发 -
composer show --platform：直接 GEThttps://packagist.org/packages.json，超时或Connection refused就说明代理服务没运行或端口不通
curl -x 是唯一能快速定位问题的命令
绕过 Composer 层，用底层 cURL 模拟等效请求，结果最可信：
- 执行
curl -x "http://user:pass@127.0.0.1:7890" -I https://packagist.org/packages.json - 返回
HTTP/1.1 200 OK→ 隧道通 - 返回
407 Proxy Authentication Required→ 密码错或 NTLM 未中转 - 返回
502 Bad Gateway→ 代理自身异常（如 Clash 规则没放行 packagist.org） - 超时或 TLS 报错 → 代理协议不支持 CONNECT 或证书被拦
环境变量和配置文件谁优先级高
Linux/macOS 下 HTTP_PROXY 和 HTTPS_PROXY 环境变量优先级高于 config.json，但大小写敏感；Windows 不区分大小写。容易踩的坑：
- 终端里设了
export HTTPS_PROXY=http://...，但值用了https://开头 → 静默失效 - 代理地址末尾带斜杠，如
http://127.0.0.1:7890/→ 解析失败 - 密码含
@或/没 URL 编码 → 认证失败且无明确提示
代理配置本身不难，难的是它和 PHP 的 OpenSSL、cURL 扩展、系统 DNS、中间人证书、镜像源开关全部耦合在一起。调不通时，别只盯着 config -g 输出，先用 curl -x 看隧道通不通，再看 php -m 有没有 openssl 和 curl。
