改系统DNS比配镜像源更关键，因为DNS解析失败会导致镜像URL根本无法发起请求；需锁定114.114.114.114等可信DNS，并在hosts中预埋mirrors.aliyun.com等域名的IPv4地址以跳过IPv6延迟。
为什么改系统DNS比配镜像源还关键
Composer 卡在 Loading composer repositories 或 Downloading https://...，90% 不是源站慢，而是 DNS 解析失败或超时。哪怕你已配置阿里云镜像，若 mirrors.aliyun.com 解析不出 IP，后续所有 HTTP 请求都直接失败——镜像 URL 再快也无从发起。
/etc/resolv.conf 只留两个可信 DNS
虚拟机或 Docker 容器内默认继承宿主机 DNS，常被劫持、缓存污染或响应超时。必须手动锁定为高可用公共 DNS：
- 编辑
/etc/resolv.conf，清空原有内容，只保留两行： nameserver 114.114.114.114nameserver 223.5.5.5
注意：若系统启用 systemd-resolved（Ubuntu/Debian 默认），它会定期覆盖 resolv.conf。需先执行 sudo systemctl disable --now systemd-resolved，再写入。
hosts 预埋关键域名 IP 防 fallback 延迟
IPv6 fallback 是最隐蔽的“卡住但不报错”原因：Composer 默认先查 IPv6 地址，超时（通常 1–3 秒）再试 IPv4。上百个包叠加就是几分钟白等。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 用
curl -v https://mirrors.aliyun.com/composer/ 2>&1 | grep "Connected to"看是否连了2a03:2880:...类 IPv6 地址 - 确认后，在
/etc/hosts中硬编码常用域名的 IPv4 地址（用dig +short mirrors.aliyun.com或nslookup mirrors.aliyun.com 114.114.114.114获取）： 223.6.6.6 mirrors.aliyun.com223.6.6.6 packagist.org223.6.6.6 github.com
这样彻底跳过 DNS 查询与 IPv6 尝试，首字节响应可从秒级降至毫秒级。
Docker Compose 中 dns 字段必须显式声明
在 docker-compose.yml 里只靠 network_mode: bridge 不够——容器仍可能继承不可靠的宿主机 DNS。必须为服务级指定：
services:
app:
image: php:8.3-cli
dns:
- 114.114.114.114
- 223.5.5.5
dns_search:
- svc.cluster.local
- internal注意：dns 字段在 network_mode: host 下完全无效；若用自定义网络，也可在 networks 定义中统一设 dns，但服务级优先级更高。
真正起效的不是“搭了个本地 DNS 服务”，而是让每次解析都走确定路径、确定 IP、确定协议——任何一层模糊，Composer 就会在黑盒里多等几秒，积少成多，就成了“怎么都慢”。
