Composer不读系统HTTP_PROXY，只认自身http-proxy和https-proxy配置；必须同时设置二者且https-proxy也用http://协议，否则HTTPS仓库请求直连超时；NTLM代理需用cntlm中转；密码含特殊字符须URL编码。
Composer 不读系统环境变量 HTTP_PROXY，只认自己配置里的 http-proxy 和 https-proxy 字段。设了环境变量却没生效？大概率是这个原因。
为什么 composer config -g http-proxy 没用
常见错因不是命令写错，而是漏配 https-proxy。Packagist、GitHub 等仓库全走 HTTPS，http-proxy 只管 HTTP 请求，对 HTTPS 请求完全无效。结果就是 composer install 卡在 “Loading composer repositories”，实际请求被直连拦截或超时。
- 必须同时运行两条命令：
composer config -g http-proxy http://127.0.0.1:8080和composer config -g https-proxy http://127.0.0.1:8080 -
https-proxy的值仍用http://开头，不是https://—— 这是 Composer 的硬性要求，填https://会静默失效 - 验证是否写入成功：
composer config -g --list | grep -E "(http-proxy|https-proxy)"，看到两行才靠谱
http://user:pass@proxy:port 里密码含 @ 或 / 怎么办
Composer 解析代理 URL 时，第一个 @ 就被当成用户/密码分隔符，后面的内容全乱。比如密码是 pa@ss/word，不编码就直接填，会解析成用户名 user、密码 pa，剩下 ss/word@proxy:port 被丢弃，报错 Invalid URI supplied 或静默跳过代理。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 用
php -r "echo rawurlencode('pa@ss/word');"得到pa%40ss%2Fword - 完整地址写成：
http://user:pa%40ss%2Fword@127.0.0.1:8080 - 域名里带
@（比如dev@corp.com）也得编码，否则同样被截断
公司用 NTLM 代理（比如 Windows 域控），407 Proxy Authentication Required 怎么破
Composer 原生不支持 NTLM 认证，设任何 http-proxy 都没用。错误现象通常是 Failed to open stream: Unable to connect to http://repo.packagist.org，或者明确返回 407。
- 不能靠改 Composer 配置解决，必须加一层本地中转代理：用
cntlm或px启一个127.0.0.1:3128的普通 HTTP 代理，再让 Composer 连它 - 确认公司是否提供免认证的 bypass 代理（有些内网有专用 HTTP 出口）
- 临时关闭代理测试：
composer config -g http-proxy '' && composer config -g https-proxy ''，完事记得恢复
代理设好了还是连不上，怎么快速定位
现象都是“卡住”“没报错”，但根本原因是链路里某环断了。别猜，用 curl 逐层验证：
- 先测本地代理进程是否活着：
curl -x http://127.0.0.1:8080 -I https://packagist.org/packages.json—— 如果这步失败，问题在代理服务本身或防火墙 - 再测 Composer 是否读到了配置：
composer diagnose输出里应有HTTP proxy: http://...行 - 注意干扰项：系统环境变量
HTTP_PROXY优先级高于 Composer 配置，冲突时建议统一用一种方式
真正难调的从来不是配置语法，而是代理链路上任意一环（本地代理进程、中间网关、企业防火墙策略）出问题，表现都一样：没错误，只有等待。
