必须同时配置http-proxy和https-proxy且均以http://开头，否则HTTPS请求静默直连导致卡在“Resolving dependencies”；Composer协议路由硬分离，缺https-proxy无法建立CONNECT隧道，所有HTTPS源（如Packagist）请求均失败。
Composer 代理配置免密认证，本质是让 composer install 走本地 HTTP 代理（如 Clash、Squid），且该代理本身不需用户名密码 —— 这种场景下，http-proxy 和 https-proxy 都必须显式配，且值必须是 http:// 协议开头，否则 HTTPS 请求会静默 fallback 到直连。
为什么只配 http-proxy 还是卡在 “Resolving dependencies”
因为 Packagist、GitHub 等所有主流源都走 HTTPS，而 Composer 对协议路由是硬分离的：http-proxy 只管 http:// 请求，https-proxy 才负责建立 CONNECT 隧道处理 https://。漏掉后者，请求就发不出去，但不会报错，只会卡住或超时。
-
https-proxy的值必须是http://127.0.0.1:8080这类格式，哪怕你的代理监听的是 TLS 端口，也不能写成https:// - 腾讯云/阿里云等 VPC 内服务器若无公网出口，优先换国内镜像源（如
https://mirrors.aliyun.com/composer/），比配代理更稳 - 验证是否生效：运行
composer config -g --list | grep -E "(http|https)-proxy"，输出里必须同时出现两行，且 URL 格式正确
composer config -g 配代理的完整命令顺序
必须两条都执行，顺序无关，但缺一不可；-g 是关键，不加就只写进当前项目，换目录就失效。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
composer config -g http-proxy http://127.0.0.1:8080composer config -g https-proxy http://127.0.0.1:8080- 如果代理监听的是
127.0.0.1:7890（Clash 默认），就把上面的端口换成7890 - 代理进程必须已启动，且防火墙允许本机访问该端口（常见坑：Clash 配置里没开
allow-lan或监听地址写成了0.0.0.0但没放行）
免密代理配错的典型现象和快速排查
没报错、没提示、就是卡住 —— 这是免密代理配错最典型的表象。根本原因往往是 https-proxy 字段缺失或协议写错。
- 填成
https://127.0.0.1:8080或127.0.0.1:8080（缺协议头）→ 请求直连，最终超时或cURL error 35 - 代理进程未运行 →
composer install会卡几秒后报Connection refused，但有时也静默失败 - 想绕过环境变量？别试 —— Composer 明确忽略
HTTP_PROXY/HTTPS_PROXY，只认自己的配置项 - 临时验证代理通不通：用
curl -x http://127.0.0.1:8080 -I https://packagist.org/packages.json，结果返回200才算通
NTLM 代理或带认证的代理不在此列
本文说的“免密认证”特指本地代理本身不需要用户名密码。如果你公司用的是 Windows 域环境下的 NTLM 代理，http://user:pass@127.0.0.1:8080 这种写法会直接失败（407 错误），因为 Composer 不支持 NTLM。这时候必须用 cntlm 或 px 做中转，让它们监听 127.0.0.1:3128 并处理认证，再让 Composer 连这个本地地址 —— 这是唯一可行路径。
