只配 http-proxy 一定失败，因为 Composer 的 HTTPS 流量（如 Packagist、GitHub）必须由 https-proxy 显式指定才能走 CONNECT 隧道，仅设 http-proxy 会导致关键请求直连而超时或报 cURL error 28。
为什么只配 http-proxy 一定失败
Composer 对 HTTP 和 HTTPS 请求走两套完全独立的代理路径：HTTP 流量走 http-proxy，HTTPS 流量必须走 https-proxy 字段发起 CONNECT 隧道。而 Packagist、GitHub、GitLab 所有仓库全量使用 HTTPS，漏掉 https-proxy 就等于让所有关键请求 fallback 到直连——结果就是卡在 Loading composer repositories，或反复报 cURL error 28，且无明确错误提示。
常见错误写法包括：
-
https://127.0.0.1:7890（协议头必须是http://） -
127.0.0.1:7890（缺协议头，静默失效） - 只运行
composer config -g http-proxy http://127.0.0.1:7890，没配https-proxy
怎么验证代理配置已加载且格式正确
别信 composer config -g --list 的输出是否“看起来完整”，要确认两行都存在且协议合规：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
composer config -g --list | grep -E "(http|https)-proxy" - 必须看到两行，且
https-proxy值以http://开头（哪怕你的代理监听的是 HTTPS 端口） - 代理地址末尾不能带斜杠：
http://127.0.0.1:7890/会解析失败 - 密码含
@或/必须 URL 编码，例如pa@ss/word→pa%40ss%2Fword
代理配对了还是卡住？真实流量没走代理的典型表现
配置存在 ≠ 流量真走代理。最可靠验证方式是触发一次真实 HTTPS 请求并抓包：
- 运行
composer global status或composer show --platform；若超时或报Connection refused，说明代理服务未运行、端口不通，或认证缺失 - Linux/macOS 下用
sudo tcpdump -i lo0 port 7890（替换为你代理端口），再执行composer require monolog/monolog，观察是否有 SYN 包发出 - 如果命令看似成功但下载极慢、部分包拉不到，大概率是代理转发异常（比如返回 502）或 TLS 握手被降级
- 临时关闭代理测试：
HTTP_PROXY= HTTPS_PROXY= composer install，若此时成功，基本锁定是代理链问题
NTLM 代理或系统级 MITM 代理怎么办
Composer 原生不支持 NTLM 认证，设了 http-proxy 也会直接返回 407 Proxy Authentication Required。也不能靠改 Composer 配置解决，必须引入中转层：
- Windows 推荐
cntlm或px，监听127.0.0.1:3128并处理 NTLM，再把 Composer 的http-proxy和https-proxy都指向http://127.0.0.1:3128 - 中文环境常见代理（Clash、Surge、Proxyman）启用 MITM 模式后，PHP 的 OpenSSL 不信任其根证书，导致
cURL error 35或握手卡死；需手动将代理根证书加入openssl.cafile或通过composer config -g cafile /path/to/cert.pem指定 - 验证中转层是否生效：
curl -x http://127.0.0.1:3128 -I https://packagist.org/packages.json，若也报 407，说明中转没配好
0.0.0.0（而非仅 127.0.0.1）、PHP 的 default_socket_timeout 是否比 http.timeout 还小、甚至 Docker 容器里写的 127.0.0.1 其实根本连不到宿主机——这些细节不逐层排除，光调 composer config 没用。 
