resolving dependencies卡住是dns解析失败，非网络或配置问题；需用dig测试、换公共dns、检查hosts、验证镜像配置（repo.packagist+斜杠）并强制clear-cache，git包还需单独处理。
Resolving dependencies卡住就是DNS问题
这一步根本没发HTTP请求，http.timeout、代理、镜像源全无效。Composer只做域名解析（比如查mirrors.aliyun.com或packagist.org的IP），失败就停在这儿，报错常是Could not resolve host或Connection refused。
- 先用
dig mirrors.aliyun.com @114.114.114.114测试DNS是否通——若超时或无ANSWER SECTION，说明本地DNS被污染或不可用 - 临时换公共DNS：
sudo echo "nameserver 8.8.8.8" >> /etc/resolv.conf（Linux/macOS）；Windows在网卡属性里手动填 - 检查
/etc/hosts（或C:\Windows\System32\drivers\etc\hosts）有没有把mirrors.aliyun.com或packagist.org指向127.0.0.1或错误IP - 用手机热点试一次——很多企业网会屏蔽这些域名，但热点直连通常能过
换镜像源必须配对repo.packagist和斜杠
镜像配置写错一个字符就静默失效，composer install仍会去连官方源，你以为换成功了，其实根本没走镜像。
- 键名必须是
repo.packagist（repo单数，不是repos） -
type值必须显式写"composer"，不能省略或拼成compose - URL必须以
https://开头，且末尾带/：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌ - 验证是否真生效：
composer config -g repo.packagist输出应为完整JSON，如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
换源后不clear-cache等于白换
Composer缓存里可能存着旧源失败的响应或损坏的packages.json，哪怕镜像已配对，它仍会从缓存读取错误数据，导致后续所有操作持续失败。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 换源命令执行完，**必须立刻运行**
composer clear-cache - 验证效果：加
--dry-run再跑一次composer install，看下载链接是否变成mirrors.aliyun.com - 如果还卡在
Resolving dependencies，说明DNS没修好，别怪镜像——镜像源本身不参与DNS解析
Git包绕过镜像，得单独处理
项目里只要用了"type": "git"的包（比如"laravel/framework": "dev-main"），Composer就会跳过镜像，直接连github.com或gitlab.com，这时候DNS问题照旧发生，且repo.packagist完全不管用。
- 这类包必须单独确保
github.com能被解析——同样靠换DNS或改hosts - 如果公司网禁GitHub，只能上代理：
composer config -g http.proxy http://127.0.0.1:8080（注意是http.proxy，不是https.proxy） - 代理带认证？URL格式必须是
http://user:pass@127.0.0.1:8080，密码含@或/要URL编码
真正麻烦的从来不是“等多久”，而是你改了http.timeout、清了缓存、换了镜像，却漏掉了/etc/hosts里一行错误绑定，或者压根没意识到git包根本不走镜像。
