报错“Could not resolve host”或“Connection timed out”本质是网络层问题，需先排查DNS解析或防火墙拦截；composer diagnose硬编码只测packagist.org，不反映镜像实际可用性；镜像失效常因缓存未清、项目级配置覆盖或URL末尾斜杠缺失；HTTP超时设置不影响git clone，后者需单独配置Git。
Could not resolve host 或 Connection timed out 这类报错，根本不是 Composer 配置或 PHP 版本的问题，而是网络层卡在 DNS 解析或 TCP 连接阶段。别改 composer.json，先确认“能不能通网”。
怎么快速判断是 DNS 还是防火墙拦截
运行 ping packagist.org：
– 如果返回 unknown host，说明 DNS 解析失败，换 DNS（比如 8.8.8.8）比调超时更直接有效；
– 如果能 ping 通但 curl -I https://packagist.org 卡住或报 Failed to connect，大概率是代理、公司防火墙或 HTTPS 策略拦截；
– 手机热点一试便知——很多学校/企业网络会统一屏蔽 packagist.org 和 github.com。
为什么换了镜像源，composer diagnose 还报错
composer diagnose 硬编码只连 https://packagist.org，它不读取你配置的镜像，也不受 COMPOSER_REPO_PACKAGIST 影响。所以它失败 ≠ 你日常 install 不能用。
– 想验证镜像是否真可用，跑 composer show -p | head -5，它走当前实际配置；
– 临时让 diagnose 测镜像，得先删掉全局镜像：composer config --global --unset repos.packagist；
– 某些企业镜像会静默丢弃非白名单 User-Agent（如 Composer/2.x），这时 diagnose 显示失败，但手动 curl -A "Composer/2.x" https://mirrors.aliyun.com/composer/packages.json 可能就通。
镜像配完没生效？缓存和项目级配置在捣鬼
换镜像后必须清缓存，否则 Composer 仍可能从旧缓存读失效地址：
– 执行 composer clear-cache；
– 检查项目根目录 composer.json 是否硬编码了 repositories，它的优先级高于全局镜像，会覆盖你设的阿里云地址；
– 清单命令：composer config -g repo.packagist 看全局是否生效，composer config repo.packagist（不加 -g）看项目级有没有冲突；
– 清华镜像注意末尾斜杠：https://mirrors.tuna.tsinghua.edu.cn/composer/ 少了 / 会 404。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
HTTP 超时设置只管元数据，不管 git clone
cURL error 28 看似超时，但 Composer 安装分两步：
– 第一步走 HTTP 请求包元数据（受 http.timeout 控制）；
– 第二步下载代码可能走 git clone（由 Git 自己决定超时），改 Composer 配置对它完全无效；
– 延长 HTTP 超时：composer config -g http.timeout 600；
– 强制跳过 git，改用 zip 下载：composer config -g github-protocols https（仅对 GitHub 包有效）；
– Git 自身超时要另配：git config --global core.sshCommand "ssh -o ConnectTimeout=30"。
真正卡住的地方，往往不是你怀疑的那个环节——diagnose 不代表真实流程，项目级 repositories 会悄悄覆盖全局配置，而 git clone 的超时跟 Composer 的 http.timeout 完全无关。
