因为Packagist全量走HTTPS，而http-proxy仅处理HTTP请求，HTTPS必须依赖https-proxy字段（值须为http://协议）建立CONNECT隧道；缺一则HTTPS请求fallback直连，导致“Loading composer repositories”卡住且无报错。
为什么只配 http-proxy 仍卡在 “Loading composer repositories”
因为 Packagist 全量走 HTTPS，而 http-proxy 只处理 HTTP 请求；HTTPS 必须靠 https-proxy 字段建立 CONNECT 隧道。漏掉它，Composer 就会把 HTTPS 请求 fallback 到直连——不报错、不提示，只默默超时或卡住。
关键点：
-
https-proxy的值必须以http://开头（不是https://），哪怕代理服务本身监听 TLS 端口 - 两个字段必须同时设置：
composer config -g http-proxy http://127.0.0.1:7890和composer config -g https-proxy http://127.0.0.1:7890 - 命令必须带
-g，否则只写入当前项目composer.json，换目录即失效 - 用户名或密码含
@、/、:时，必须 URL 编码，例如pa@ss/word→pa%40ss%2Fword
代理和镜像源能不能一起用
不能。二者作用层面不同，且 Composer 明确互斥：设了 repo.packagist 镜像，http-proxy 和 https-proxy 就完全被忽略；反之，开了代理，镜像配置就形同虚设。
混配的典型现象：
-
composer install卡在 “Loading composer repositories”，日志里既没出现镜像域名，也没出现 Proxy CONNECT - 静默失败，无错误信息，只等超时
- TLS 握手错误（如
SSL operation failed）或cURL error 28
正确做法：要么清空镜像（composer config -g --unset repo.packagist）再配代理，要么只配镜像并确保其地址可直连。
怎么验证代理真的生效了
别信 composer config -g --list 输出里有字段，要看真实网络行为。
可靠验证方式：
- 先清缓存：
composer clear-cache，否则本地旧元数据不触发网络请求 - 加调试参数运行：
composer install -n -vvv 2>&1 | grep "Proxy CONNECT\|Downloading" - 看到
Proxy CONNECT行，说明 HTTPS 流量确实进了代理隧道 - 看到
Downloading https://packagist.org/...但没Proxy CONNECT，说明代理没走通，还在直连 - 临时用
curl -x http://127.0.0.1:7890 -I https://packagist.org/packages.json单独测代理连通性
企业内网 NTLM 代理怎么办
Composer 原生不支持 NTLM 认证，设了 http-proxy 也会直接返回 407 Proxy Authentication Required 或连接失败。
必须引入中转代理工具：
- Windows 域环境推荐
cntlm或px，让它们监听127.0.0.1:3128并处理 NTLM - 再把 Composer 的
http-proxy和https-proxy都指向这个本地地址（如http://127.0.0.1:3128） - 验证中转层是否正常：
curl -x http://127.0.0.1:3128 -I https://packagist.org/packages.json应返回 200 - 别指望
HTTP_PROXY环境变量——Composer 明确忽略它
真正容易被忽略的是：NTLM 不是配置问题，是协议支持问题；想绕过它，只能靠中转，没有纯配置解法。
