Resolving dependencies卡住是DNS解析问题，非Composer配置错误；需用dig验证DNS、换公共DNS、修正hosts绑定、禁用systemd-resolved，并确保镜像URL末尾带斜杠。
Resolving dependencies卡住就是DNS问题
Composer停在Resolving dependencies时，压根没发HTTP请求，只做域名解析（比如查mirrors.aliyun.com或packagist.org的IP），http.timeout和代理完全无效。这时候调超时、换源、清缓存全白搭。
- 先验证：运行
dig mirrors.aliyun.com @114.114.114.114，看是否返回有效IPv4地址；若超时或无响应，说明本地DNS不可用或被污染 - 临时改系统DNS：Linux/macOS编辑
/etc/resolv.conf加nameserver 8.8.8.8；Windows在网卡里手动设 - 别信宿主机继承的DNS——虚拟机、Docker、WSL2默认走这路，但NAT层常导致DNS查询延迟翻倍甚至丢包
hosts预绑定关键域名最稳
DNS解析慢的本质是多跳+重试+超时叠加。直接在/etc/hosts（Windows为C:\Windows\System32\drivers\etc\hosts）写死IP，能跳过全部链路环节。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 查真实IP：用
dig mirrors.aliyun.com +short或国外VPS上ping mirrors.aliyun.com获取当前可用IPv4 - 追加行示例：
120.52.117.10 mirrors.aliyun.com（IP以实际查询为准，阿里云镜像IP会变，建议每月check一次） - 注意别误写成
127.0.0.1 mirrors.aliyun.com——这是常见手误，会导致彻底连不上
虚拟机/Docker必须禁用systemd-resolved
很多Linux发行版（Ubuntu 18.04+、Fedora等）默认启用systemd-resolved，它会在本地开53端口做DNS代理，但和Docker、VirtualBox的NAT网络存在兼容性问题，造成随机解析超时或返回空响应。
- 检查是否运行：
systemctl is-active systemd-resolved - 临时停用：
sudo systemctl stop systemd-resolved - 永久禁用（推荐）：
sudo systemctl disable systemd-resolved，再删掉/etc/resolv.conf软链，重建为普通文件并填入nameserver 223.5.5.5 - Docker用户额外加一条：
echo '{"dns": ["223.5.5.5", "114.114.114.114"]}' | sudo tee /etc/docker/daemon.json，然后sudo systemctl restart docker
阿里云镜像源URL末尾斜杠不能少
配置镜像源时漏掉结尾/是静默失效的高发原因——Composer会把https://mirrors.aliyun.com/composer拼成https://mirrors.aliyun.com/composerpackages.json，结果404，但错误日志不报源配置问题，只显示“Could not resolve host”这类误导信息。
- 正确命令：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意末尾/） - 验证是否生效：
composer config -g repo.packagist输出必须是完整JSON对象，含"url": "https://mirrors.aliyun.com/composer/" - 换源后务必执行
composer clear-cache，否则旧缓存仍会尝试访问失败地址
Resolving dependencies就会突然卡住，且毫无征兆。 
