https-proxy 必须以 http:// 开头，因 composer 对 https 代理硬编码为 connect 隧道模式，仅校验能否发起隧道请求，不验证代理是否监听 https；填 https:// 或无协议会静默失效。
https-proxy 必须写成 http:// 开头
Composer 对 HTTPS 流量的代理处理是硬编码为 CONNECT 隧道模式，它只关心你填的 https-proxy 字段值是否能发起隧道请求，不验证代理服务本身是否监听 HTTPS。所以哪怕你的代理（如 Clash、Proxyman）开了 TLS 端口（比如 7890 或 8443），https-proxy 的值也必须是 http://127.0.0.1:7890 这种格式。
填 https://127.0.0.1:7890 或直接写 127.0.0.1:7890 都会静默失效——没有报错，但所有 HTTPS 请求（包括访问 https://packagist.org/packages.json）全部 fallback 直连，结果就是卡在 Loading composer repositories 或报 cURL error 28。
常见错误写法：
-
composer config -g https-proxy https://127.0.0.1:7890❌ -
composer config -g https-proxy 127.0.0.1:7890❌ -
composer config -g https-proxy http://user:pass@127.0.0.1:7890✅（但密码含@或/要 URL 编码）
http-proxy 和 https-proxy 必须成对出现
Composer 不会复用 http-proxy 去处理 HTTPS 请求。HTTP 和 HTTPS 是两条完全独立的代理路径：前者走普通转发，后者必须靠 https-proxy 触发 CONNECT。Packagist、GitHub、GitLab 所有仓库元数据全走 HTTPS，漏掉任一字段，就等于让关键请求裸奔。
验证是否配齐：
- 运行
composer config -g --list | grep -E "(http|https)-proxy" - 输出必须包含两行，且都以
http://开头 - 如果只看到
http-proxy，说明https-proxy没设或设错了
别指望系统环境变量 HTTP_PROXY 或 HTTPS_PROXY 能替代——Composer 明确忽略它们。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
带认证的代理怎么填密码
用户名/密码里含 @、/、: 时，必须做 URL 编码，否则 Composer 解析 URL 会截断。
例如密码是 pa@ss/word，要写成 pa%40ss%2Fword：
- 快速生成命令：
php -r "echo rawurlencode('pa@ss/word');" - 完整配置示例：
composer config -g https-proxy http://user:pa%40ss%2Fword@127.0.0.1:8080 - 注意：冒号
:也要编码为%3A，但多数代理服务不常用在密码中
填错会导致配置写入失败，或写入后被解析为空值，现象仍是卡住无响应。
NTLM 代理（如公司 Windows 域）怎么办
Composer 原生不支持 NTLM 认证。直接设 http-proxy 会返回 407 Proxy Authentication Required，不是配置姿势问题，是协议层不兼容。
必须引入中转代理：
- Windows 推荐
cntlm或px，监听127.0.0.1:3128并处理 NTLM - 然后把 Composer 的两个字段都指向这个本地地址：
http://127.0.0.1:3128 - 验证中转是否生效：
curl -x http://127.0.0.1:3128 -I https://packagist.org/packages.json，若仍报 407，说明中转没跑起来或没配好域凭据
这一步绕不开，改 auth.json 或加 http-basic 没用——那是给私有包仓库用的，和出站代理无关。
