必须同时配置http-proxy和https-proxy，且https-proxy值必须以http://开头；因Composer所有仓库均走HTTPS，仅配http-proxy会导致HTTPS请求静默直连而超时或报cURL error 28。
必须同时配置 http-proxy 和 https-proxy，且 https-proxy 的值协议头必须是 http://——漏掉或写错格式，HTTPS 请求就会静默直连，卡在 Loading composer repositories 或反复报 cURL error 28。
为什么只配 http-proxy 一定失败
Composer 对 HTTP 和 HTTPS 请求走完全不同的代理路径：HTTP 请求走 http-proxy 字段，而所有仓库（Packagist、GitHub、GitLab）全量使用 HTTPS，必须经 https-proxy 发起 CONNECT 隧道。只设 http-proxy 等于让 HTTPS 流量绕过代理直接发出去，在国内网络环境下基本必超时。
- 常见错误现象：
composer install卡住无响应，composer config -g --list只显示http-proxy行，没看到https-proxy - 错误写法示例：
https://127.0.0.1:8080或127.0.0.1:8080—— 这两种都会静默失效 - 正确写法必须以
http://开头，例如：http://127.0.0.1:7890（Clash）、http://user:pa%40ss%2Fword@127.0.0.1:8080（含特殊字符需 URL 编码）
https-proxy 配好后仍超时？先查 PHP 底层限制
代理只是链路一环，https-proxy 生效的前提是 PHP 自身不提前掐断连接。Composer 的 http.timeout 再大，也敌不过 PHP 的 default_socket_timeout 默认值（常为 60 秒）。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 查当前值：
php -i | grep default_socket_timeout - 临时覆盖：
php -d default_socket_timeout=600 composer install - 永久修改：编辑
php.ini，设default_socket_timeout = 600，然后重启 PHP-FPM 或 CLI 环境 - 同步调高 Composer 的
http.timeout：composer config -g http.timeout 600（单位秒）
NTLM 代理（如公司域环境）怎么办
Composer 原生不支持 NTLM 认证，设了 http-proxy 和 https-proxy 也会直接返回 407 Proxy Authentication Required。
- 必须引入中转代理工具：Windows 推荐
cntlm或px，让它们监听127.0.0.1:3128并处理 NTLM 认证 - 再把 Composer 的两个 proxy 都指向中转地址：
http://127.0.0.1:3128 - 验证中转是否生效：
curl -x http://127.0.0.1:3128 -I https://packagist.org/packages.json；若也报 407，说明中转层没配通
换源 + 代理都配了还卡？确认是否真走 HTTPS 流量
有些项目硬编码了 repositories，或依赖私有 Git 包（如 git@github.com:user/repo.git），这些不会走 Composer 镜像源，也不经过 https-proxy，而是走 SSH 或 Git 协议。
- 检查
composer.json里的repositories字段，清理冗余或冲突配置 - 私有 GitHub 包建议改用 HTTPS 克隆：
"https://github.com/user/repo.git"，并配好 GitHub Token（写入~/.composer/auth.json） - Git 克隆阶段超时，和
https-proxy无关，要单独设GIT_SSH_COMMAND="ssh -o ConnectTimeout=10"或禁用--prefer-source
最容易被忽略的是：代理配置和 PHP 超时参数必须成对调整，缺一不可；而 NTLM 场景下，Composer 本身无法解决认证问题，必须靠中转代理补足这一环。
