因为Packagist全量走HTTPS，而http-proxy仅处理HTTP请求，HTTPS必须由https-proxy通过CONNECT隧道转发；漏配https-proxy会导致直连超时或502错误。
为什么只配 http-proxy 仍然卡在 “Loading composer repositories”
因为 Packagist 和绝大多数 Composer 仓库全量走 HTTPS，而 http-proxy 只对 HTTP 协议生效。HTTPS 请求必须由 https-proxy 处理 CONNECT 隧道——漏掉它，Composer 就会尝试直连，结果超时、502 或静默卡住。
常见现象包括：Resolving dependencies 停住不动、cURL error 35、或 Failed to decode response。这不是网络慢，是协议路由没对上。
-
https-proxy的值必须是http://开头（哪怕代理本身监听 HTTPS 端口），例如http://127.0.0.1:8080 - 若需认证，用户名密码要 URL 编码：
http://user:pa%40ss%2Fword@127.0.0.1:8080 - Windows 下注意权限：若报
Could not write to file，检查%APPDATA%\Composer\config.json是否可写
全局代理配置的正确命令与验证方式
必须用 -g（即 --global）参数，否则只改当前项目，换目录就失效。两条命令缺一不可：
composer config -g http-proxy http://127.0.0.1:8080composer config -g https-proxy http://127.0.0.1:8080
验证是否真正生效，别信“命令执行成功”：
composer config -g --list | grep -E "(http|https)-proxy" —— 输出应有两行，且 URL 格式正确
再跑一次 composer install -vvv 2>&1 | grep "Downloading"，确认所有 URL 都经由代理发出（能看到代理地址出现在 curl 日志里）
公司用 NTLM 代理或 Clash/Proxifier 不支持 CONNECT 隧道怎么办
Composer 原生不支持 NTLM 认证，设了 http-proxy 也会直接返回 407 Proxy Authentication Required。这不是 Composer 配置问题，而是协议层不兼容。
必须引入中转代理工具：
- Windows 域环境：用
cntlm或px监听127.0.0.1:3128，处理 NTLM 后，再让 Composer 连这个本地地址 - Clash/Proxifier：确保规则包含
DOMAIN-SUFFIX,packagist.org,PROXY，且启用 HTTPS 的 CONNECT 隧道支持 - 快速验证：用
curl -x http://127.0.0.1:3128 -I https://packagist.org/packages.json测试，如果 curl 也报错，说明中转层没配通
代理不稳定时，优先切镜像源而不是硬扛代理
即使开了代理，若隧道不稳定或同步延迟，composer install 仍可能失败。此时全局切换国内镜像比调代理更可靠：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
注意三点：
- 键名是
repo.packagist（单数，不是repos） - type 值必须显式写
composer，不能省略 - URL 必须以
/结尾，且为 HTTPS
切完立刻验证：composer config -g repo.packagist 应输出完整 JSON 对象，如 {"type":"composer","url":"https://mirrors.aliyun.com/composer/"}。项目里若有手动写的 "repositories" 块，记得删掉，否则会覆盖全局设置。
最常被忽略的是：镜像和代理不是二选一，而是分层策略——先确保源可用（镜像），再考虑传输路径（代理）。很多人卡在第一步却花时间调第二步。
