Composer diagnose 总卡在 packagist.org 是因硬编码只测该域名且不读镜像配置；真实问题常为 DNS 解析失败、IPv6 路由黑洞或代理配置错误，需逐层验证并手动干预。
Composer 本身不支持自动探测和切换链路，所谓“自适应”必须靠你手动配置环境或镜像策略来模拟。
composer diagnose 为什么总卡在 packagist.org？
它硬编码只测 https://packagist.org，完全不读你的镜像源配置。哪怕你日常用阿里云镜像完全正常，composer diagnose 仍可能失败——这不是你配错了，是它故意撞墙。
- 加
-vvv看真实错误：composer diagnose -vvv会输出 cURL 错误码（比如error 28是超时，error 7是连接拒绝） - 想验证当前镜像是否真可用，别信
diagnose，直接跑：composer show -p | head -5，这条命令走的是你实际生效的配置链路 - 临时让
diagnose过关？删掉镜像再试：composer config --global --unset repos.packagist.org
CURL_IPRESOLVE=4 能绕过 IPv6 路由黑洞
很多网络（尤其教育网、某些 WSL 或 Docker 环境）IPv6 路由不通，但系统仍优先尝试 IPv6 地址（如 2a03:2880::），导致卡住或超时。cURL 层面强制走 IPv4 是最轻量解法。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- Linux/macOS 临时生效：
CURL_IPRESOLVE=4 composer install - Windows 命令行：
set CURL_IPRESOLVE=4 && composer install - 别动 PHP 或重装系统——Composer 2.2+ 默认走 cURL，而 cURL 就认这个变量
- 记得保持
COMPOSER_DISABLE_TLS=false，否则 HTTPS 校验被绕过，诊断结果失真
镜像源不是万能的，DNS 解析失败时它根本没机会启动
Could not resolve host 错误永远发生在第一步：域名压根没解析出 IP。此时换镜像源、配代理、清缓存全无效。
- 先验证 DNS：
nslookup mirrors.aliyun.com 8.8.8.8，无 ANSWER SECTION → 本地 DNS 服务器不响应 - 确认是否污染：
dig mirrors.aliyun.com @1.1.1.1 +short能返回 IP，但不用该 DNS 就查不到 → 运营商 DNS 被污染 - hosts 绑定是最稳的应急方案：
223.5.5.5 mirrors.aliyun.com，追加到/etc/hosts（Linux/macOS）或C:\Windows\System32\drivers\etc\hosts（Windows） - 注意：Composer 2.5+ 启动时仍会尝试解析原始域名做校验，DNS 不通，光配镜像源没用
代理配置必须显式写进 Composer 配置，环境变量无效
Composer 完全忽略 http_proxy、HTTPS_PROXY 等系统变量，只认自己配置文件里的字段。
- 正确写法：
composer config -g http-proxy http://127.0.0.1:7890和composer config -g https-proxy http://127.0.0.1:7890（注意：https-proxy 的值也必须是http://开头） - 旧写法
proxy（无 s）已被弃用；键名过时（如repo.packagist）在 Composer 2.2+ 中会被静默忽略 - 含特殊字符的账号密码需 URL 编码：
user%40domain:pass%40word@127.0.0.1:7890 - NTLM 代理不被原生支持，必须前置
cntlm或px做中转
真正麻烦的从来不是某条命令跑不通，而是错误堆叠：DNS 没通 → 镜像源配了也白配；IPv6 路由卡死 → 强制走 IPv4 才能继续；代理填错协议 → 直接静默失败。每层都得单独验证，不能指望一键修复。
