Composer卡在“Loading composer repositories”根本原因是https-proxy缺失或格式错误：必须同时配置http-proxy和https-proxy且均以http://开头，否则HTTPS请求静默直连失败；密码含@、/等字符需URL编码，代理软件须启用系统代理模式并监听127.0.0.1。
Composer 在启用代理软件（如 Clash、Surge、Proxyman 或企业级 HTTPS 解密网关）后，composer install 或 composer require 卡在 “Loading composer repositories” 且无报错、无超时、无响应——这几乎肯定是 HTTPS 代理隧道未正确建立导致的静默阻塞，不是网络不通，而是请求被“吞掉”了。
为什么只配 http-proxy 还是卡住
Composer 严格按协议路由代理：http-proxy 只用于 HTTP 请求，而 Packagist、GitHub 等全部走 HTTPS，必须由 https-proxy 建立 CONNECT 隧道。漏掉后者，Composer 就 fallback 到直连，在代理软件接管所有出站流量的环境下，等同于把请求发进黑洞。
- 运行
composer config -g --list | grep -E "(http|https)-proxy"，输出必须同时包含两行，缺一不可 -
https-proxy的值必须以http://开头，哪怕你用的是 HTTPS 代理服务（这是 Composer 的硬性约定） - 常见错误写法：
https://127.0.0.1:7890❌、socks5://127.0.0.1:7891❌（Composer 不支持 SOCKS）
https-proxy 值含特殊字符时解析失败
Composer 解析代理 URL 时，第一个 @ 就被当作用户名/密码分隔符，后续内容全被截断。例如 http://user:pa@ss/word@127.0.0.1:7890 实际只取到密码 pa，其余丢弃，最终触发 Invalid URI supplied 或静默跳过代理。
- 必须对用户名或密码中的
@、/、:做rawurlencode()编码 - 执行
php -r "echo rawurlencode('pa@ss/word');"得到pa%40ss%2Fword - 完整配置：
composer config -g https-proxy http://user:pa%40ss%2Fword@127.0.0.1:7890
代理软件开启 HTTPS 解密（MITM）时证书校验失败
Clash for Windows、Surge、Zscaler 等开启 HTTPS 解密后，会用自己的根证书签发中间证书。Composer 默认校验证书链，若系统未信任该根证书，TLS 握手就卡在 CONNECT 阶段，表现为命令挂起 30–60 秒后无声退出或直接报 SSL connect error。
- 临时验证：加环境变量绕过校验
COMPOSER_DISABLE_TLS=1 composer install，若成功说明是证书问题 - 长期方案：将代理软件的根证书导出为 PEM，加入系统 CA 证书库（Linux 执行
sudo cp cert.pem /usr/local/share/ca-certificates/ && sudo update-ca-certificates） - 不推荐全局禁用 TLS，尤其在 CI/CD 或共享环境中
代理软件监听地址不是 127.0.0.1 导致请求发错地方
部分代理客户端（如某些 Clash GUI 版本）默认监听 127.0.0.1:7890，但 macOS 或新版 Windows 启用“仅 IPv6 回环”或防火墙策略后，127.0.0.1 可能不通，而 ::1 或 localhost 才有效；也有代理监听 0.0.0.0:7890，但 Composer 不支持绑定到通配地址。
- 检查代理实际监听地址：macOS/Linux 运行
lsof -i :7890，Windows 运行netstat -ano | findstr :7890 - 若显示
*:7890或0.0.0.0:7890，需在代理设置中显式改为127.0.0.1:7890 - 若显示
[::1]:7890，尝试把https-proxy改为http://[::1]:7890（注意方括号）
最易被忽略的是：代理软件本身是否真正处于“系统代理模式”并已启用。很多 GUI 工具默认只代理浏览器，终端流量仍走直连——务必确认其“System Proxy”或“Enable TUN Mode”开关已打开，且状态栏图标显示“已启用”。
