答案是DNS污染导致镜像域名无法解析，需先用nslookup对比干净DNS与本地DNS解析结果确认污染，再用curl --resolve直连验证镜像服务，最后通过hosts绑定最新IP并刷新缓存彻底解决。
因为这些镜像域名（如 mirrors.aliyun.com、mirrors.cloud.tencent.com）正遭遇区域性 DNS 污染，你的本地系统根本查不到它们的真实 IP，后续所有请求都发不出去——不是镜像挂了，是“名字认不出来”。
先确认是不是 DNS 污染，别急着换源
执行这两条命令，结果比任何配置都准：
-
nslookup mirrors.aliyun.com 1.1.1.1—— 如果返回 IPv4 地址（比如223.5.5.5），说明干净 DNS 能解析，你本地 DNS 被污染 -
nslookup mirrors.aliyun.com（不指定 DNS）—— 如果超时或返回*** Can't find mirrors.aliyun.com: Non-existent domain，就是污染实锤
只要第一条通、第二条不通，就不用查代理、不用清缓存、不用重装 Composer，直接进下一步。
用 curl --resolve 5 秒验证镜像服务本身是否正常
跳过你本地的 DNS，强制走已知可用 IP 发请求，这是最快排除干扰的方法：
- 先查真实 IP：
dig mirrors.aliyun.com @223.5.5.5 +short | head -n1 - 再直连测试：
curl -I --resolve mirrors.aliyun.com:443:223.5.5.5 https://mirrors.aliyun.com/composer/packages.json
如果返回 HTTP/2 200 和 Content-Type: application/json，说明镜像服务完全正常，问题纯属 DNS；如果报 SSL 错误，再检查系统证书或代理；如果超时，才考虑网络策略拦截。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
hosts 绑定是最稳的落地方案，但三处容易出错
临时改 DNS 或用 --resolve 不适合 CI/CD 或多机部署，手动绑定才是生产环境首选，但以下三点必须同时满足：
- IP 必须最新：别用网上搜到的旧地址，每次执行
dig mirrors.aliyun.com @8.8.8.8 +short | head -n1拿当前有效 IP - hosts 格式必须严格：Linux/macOS 编辑
/etc/hosts，Windows 编辑C:\Windows\System32\drivers\etc\hosts，写成223.5.5.5 mirrors.aliyun.com（IP 和域名之间只能是空格，不能是 Tab 或中文符号） - 缓存必须刷新：macOS 执行
sudo dscacheutil -flushcache，Windows 执行ipconfig /flushdns，Linux systemd 系统执行sudo systemd-resolve --flush-caches
杀毒软件（如火绒、360）常锁死 hosts 文件，保存失败时务必右键编辑器选“以管理员身份运行”。
换源后仍解析失败？镜像地址末尾斜杠和项目级配置在暗中作祟
即使绑好了 hosts，composer install 还报 Could not resolve host，大概率是这两个隐形问题：
- 镜像 URL 少了末尾
/：写成https://mirrors.aliyun.com/composer会导致 Composer 拼出/composerpackages.json，触发 404 后自动弃用该源，必须是https://mirrors.aliyun.com/composer/ - 项目
composer.json里有"repositories"字段：哪怕只是空数组"repositories": []，也会彻底屏蔽全局镜像配置，运行composer config repositories查看是否仍有https://repo.packagist.org；临时禁用用composer config --unset repositories
DNS 污染是瞬时的，但 hosts 绑定、URL 斜杠、项目级配置这三样，一旦写错就会持续生效——它们不报错，只安静地退回官方源，让你以为“镜像又不行了”。
