必须同时配置http-proxy和https-proxy，因Packagist全量使用HTTPS，而Composer严格分离代理路由：http-proxy仅处理HTTP请求，https-proxy（值须为http://协议）才负责HTTPS的CONNECT隧道；缺一则HTTPS请求直连超时或502。
必须同时配置 http-proxy 和 https-proxy 两个字段，否则 composer install 会卡在 “Loading composer repositories” 且无明确错误。
为什么只配 http-proxy 还是连不上 Packagist
Packagist 所有元数据请求（如 /packages.json）都走 HTTPS，而 Composer 对代理协议严格分离：
-
http-proxy只用于纯 HTTP 请求，对 HTTPS 完全无效 -
https-proxy才负责建立 CONNECT 隧道——但它值必须是http://开头，哪怕代理本身监听 TLS 端口 - 漏掉任一字段，HTTPS 请求就会 fallback 到直连，结果通常是超时或 502，而不是报错
全局代理怎么设才生效
执行命令时一定要加 -g（即 --global），否则只写入当前项目 composer.json，换目录就失效：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 设置 HTTP 代理：
composer config -g http-proxy http://127.0.0.1:7890 - 设置 HTTPS 代理：
composer config -g https-proxy http://127.0.0.1:7890 - 带认证的写法：
composer config -g https-proxy http://user:pa%40ss%2Fword@127.0.0.1:7890（密码含@、/必须 URL 编码） - 验证是否写入成功：
composer config -g --list | grep -E "(http|https)-proxy"，应看到两行且格式正确
NTLM 代理（比如公司域环境）怎么办
Composer 原生不支持 NTLM 认证，设了 http-proxy 也会直接返回 407 Proxy Authentication Required 或连接失败：
- 不能靠改 Composer 配置解决，必须用中转工具，例如
cntlm或px - 让中转工具监听
127.0.0.1:3128并处理 NTLM，再把 Composer 的https-proxy指向这个本地地址 - 临时验证是否是 NTLM 问题：
curl -x http://127.0.0.1:3128 -I https://packagist.org/packages.json，如果 curl 也报 407，说明中转没配好 - 别指望系统
HTTP_PROXY环境变量——Composer 明确忽略它
局部代理其实是伪命题，但有变通路径
Composer 2.0+ 已废弃项目级 http-proxy 字段，所谓“局部代理”只能通过仓库粒度配置实现，且仅对 Packagist 官方源有效：
- 执行：
composer config repo.packagist.org.proxy http://127.0.0.1:7890（不加-g） - 再配 SSL 版本：
composer config repo.packagist.org.ssl-proxy http://127.0.0.1:7890 - 该配置只影响
https://repo.packagist.org及其子路径，对 GitHub、GitLab、私有 VCS 源完全无效 - 若已配置阿里云镜像（
repo.packagist指向https://mirrors.aliyun.com/composer/），这个repo.packagist.org.proxy就会被彻底忽略
最容易被忽略的是：代理配置和镜像源是两套独立机制，混用时优先级容易误判；真正卡住的时候，往往不是没配代理，而是配了却没配全、或配了却被镜像覆盖了。
