Composer install默认不走系统代理，因其完全忽略HTTP_PROXY/HTTPS_PROXY环境变量，仅识别自身配置的http-proxy和https-proxy字段；二者必须同时存在且协议匹配（https-proxy值须为http://开头），否则HTTPS请求将静默直连导致卡在“Loading composer repositories”。
composer install 为什么默认不走系统代理
因为 Composer 完全忽略 HTTP_PROXY 和 HTTPS_PROXY 环境变量，只认自己配置里的 http-proxy 和 https-proxy 两个字段。漏掉任意一个，或只设了 http-proxy，所有 HTTPS 请求（包括访问 https://packagist.org 或镜像站）都会 fallback 直连——结果就是卡在 Loading composer repositories，无报错、无提示。
强制走代理的三步硬性操作
想让 Composer 真正走代理，必须同时满足以下三点，缺一不可：
- 执行
composer config -g --unset repo.packagist（注意不是repos.packagist或packagist.org），清空镜像配置；否则代理字段被完全忽略 - 两条命令都得运行：
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://或漏协议头会导致静默失效 - 用户名或密码含
@、/、:时，必须 URL 编码，例如pa@ss/word→pa%40ss%2Fword；可用php -r "echo rawurlencode('pa@ss/word');"生成
验证是否真走代理
别信 composer diagnose，它只测官方源，和你配的代理无关。真正有效的验证方式只有两种：
- 加
-n -vvv运行命令，比如composer install -n -vvv，日志里出现Proxy CONNECT才算成功 - 用
curl -x http://127.0.0.1:8080 -I https://packagist.org/packages.json手动测试；如果返回200且Content-Type: application/json，说明代理本身可用
Windows + WSL2 用户还要额外检查主机与子系统时间是否同步，偏差超 5 分钟会直接导致 TLS 握手失败，哪怕代理和证书都对。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
https-proxy 填错的典型表现
填成 https://127.0.0.1:8080 或 127.0.0.1:8080（漏协议头）后，Composer 不报错，但所有 HTTPS 请求都直连——现象是：依赖解析卡住、cURL error 28、Connection refused，或者公司内网环境下返回 HTML 登录页而非 JSON。
更隐蔽的问题是 NTLM 代理（如 Windows 域环境），Composer 原生不支持，设了 http-proxy 也会返回 407 Proxy Authentication Required。这时必须用 cntlm 或 px 在本地起中转代理，再让 Composer 连 http://127.0.0.1:3128。
企业网络里最容易被忽略的一点：代理可能劫持 HTTPS 响应，把 https://mirrors.aliyun.com/composer/packages.json 重定向成登录页或缓存 HTML，而 Composer 不校验 Content-Type，直接解析 JSON 失败就放弃该源——此时 curl 验证响应头比任何配置检查都管用。
