因为Packagist全量走HTTPS，而http-proxy仅处理HTTP请求，HTTPS必须依赖https-proxy字段建立CONNECT隧道；漏配https-proxy会导致Composer fallback直连，被公司网络拦截后静默卡在“Loading composer repositories”并超时失败。
为什么只配 http-proxy 会卡在 “Loading composer repositories”
因为 Packagist 全量走 HTTPS，而 http-proxy 只处理 HTTP 请求；HTTPS 必须靠 https-proxy 字段建立 CONNECT 隧道。漏掉后者，Composer 就 fallback 到直连——但公司网络通常拦截所有未过代理的 HTTPS 流量，结果就是静默卡住、无报错、超时后失败。
常见错误现象：
- 执行
composer install卡在Loading composer repositories，等几分钟后报cURL error 28或直接退出 -
composer config -g --list显示只有http-proxy，没出现https-proxy - 用
curl -x http://127.0.0.1:8080 https://packagist.org/packages.json能通，但 Composer 不行——说明代理本身可用，只是没被正确启用
实操要点：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须同时设置两个字段：
composer config -g http-proxy http://user:pass@127.0.0.1:8080和composer config -g https-proxy http://user:pass@127.0.0.1:8080 -
https-proxy的值必须以http://开头，哪怕代理监听的是 TLS 端口（如https://127.0.0.1:8080是错的） - 用户名或密码含
@、/、:，必须 URL 编码，例如pa@ss/word→pa%40ss%2Fword，可用php -r "echo rawurlencode('pa@ss/word');"生成 - Windows 下若提示
Could not write to file，检查%APPDATA%\Composer\config.json是否存在且有写权限
镜像源和代理能不能一起用
不能。二者互斥：设了 repo.packagist 镜像，http-proxy 和 https-proxy 就被完全忽略；开了代理，镜像配置就形同虚设。
国内用户卡住，90% 是因为同时配了阿里云镜像和公司代理——Composer 实际走镜像直连，但公司网络策略又强制所有 HTTPS 过代理，结果请求被拦截或 TLS 握手失败。
实操要点：
- 想用代理，第一步永远是清空镜像：
composer config -g --unset repo.packagist（注意不是repos.packagist或packagist.org） - 镜像本身不参与 TLS 握手，也不支持客户端证书（mTLS）；要连私有 mTLS 源，必须用代理
- 如果公司镜像站地址仍是 HTTPS（如
https://mirrors.aliyun.com/composer/），且网络策略强制 HTTPS 过代理，那即使用了镜像，也得配https-proxy才能通
NTLM 代理（如 Windows 域环境）怎么配
Composer 原生不支持 NTLM 认证。设了 http-proxy 也会直接返回 407 Proxy Authentication Required 或 Unable to connect to http://repo.packagist.org。
这不是 Composer 配置问题，而是协议层不兼容。必须引入中转代理工具，让它们处理 NTLM，再暴露一个标准 HTTP 代理端口给 Composer 连。
实操要点：
- 推荐用
cntlm或px：它们监听127.0.0.1:3128，接受标准 HTTP CONNECT 请求，内部完成 NTLM 认证 - 然后配 Composer：
composer config -g http-proxy http://127.0.0.1:3128和composer config -g https-proxy http://127.0.0.1:3128 - 验证中转是否生效：
curl -x http://127.0.0.1:3128 -I https://packagist.org/packages.json，如果也报 407，说明 cntlm/px 没配好或没启动 - 别指望系统级
HTTP_PROXY环境变量——Composer 明确忽略它，只认自己的字段
代理配好了还是慢或失败，怎么快速定位
现象一致（卡住、超时、无报错），但原因可能在任意一层：本地代理进程未启动、防火墙拦截、证书不被信任、时间不同步……日志里不会直接说“代理连不上”，而是表现为 TLS 错误或连接拒绝。
实操要点：
- 加
-n -vvv运行命令，比如composer install -n -vvv，看日志里是否出现Proxy CONNECT——这是唯一确认真走代理的证据 - 运行
composer config -g cafile /path/to/your-root.pem指向公司根证书（不要用系统默认的ca-bundle.crt） - Windows + WSL2 用户常因时间不同步导致 TLS 握手失败，运行
sudo hwclock -s同步主机时间 - 临时提高容忍度：
composer config -g http.connect_timeout 60和composer config -g http.timeout 600 - SOCKS5 代理（如 Clash TUN 模式）需 Composer ≥ 2.2，且写法为
socks5://127.0.0.1:7891；旧版不识别，会静默 fallback
最易被忽略的点是：代理配置生效的前提是镜像已清空，且 https-proxy 协议头写对、认证信息编码正确、CA 证书路径可读——少一个，就回到直连状态，而你根本不知道。
