Composer不走本地DNS，其DNS解析由PHP cURL完成，受系统DNS影响；Docker中需显式指定--dns，镜像URL须含末尾斜杠和HTTPS，且换源后必须清缓存并删除vendor与composer.lock才能生效。
Composer 本身不走本地 DNS，别被名字误导
Composer 的包下载和元数据请求是纯 HTTP(S) 客户端行为，它不调用系统 getaddrinfo() 或读取 /etc/resolv.conf，所以改宿主机的 DNS（比如设成 114.114.114.114）对 composer install 几乎没用。真正卡住的地方是 TLS 握手前的 DNS 解析——但这个解析由 PHP cURL 扩展完成，而 cURL 默认会用系统 DNS，问题就出在这里：某些环境（尤其是 Docker、内网、WSL2）下系统 DNS 配置不可靠，导致解析 packagist.org 或镜像域名超时。
在 Docker 容器里跑 Composer，必须显式指定 DNS
很多 CI 环境或本地开发用 docker run 或 docker-compose 启动 Composer，此时容器默认继承宿主机 DNS，而宿主机可能用了 systemd-resolved、dnsmasq 或公司代理 DNS，结果解析慢或失败。解决方法不是“优化本地 DNS”，而是绕过它：
- 启动容器时加
--dns 8.8.8.8 --dns 114.114.114.114（推荐双 DNS 防单点故障） - 在
docker-compose.yml的服务中写死：services: app: dns: - 8.8.8.8 - 114.114.114.114 - 避免用
network_mode: host—— 这种模式下dns字段被完全忽略，容器直接用宿主机网络栈，DNS 问题照旧
镜像源 URL 末尾斜杠 + HTTPS 是硬性要求，否则 DNS 解析会白忙
即使你指定了正确的 DNS，如果镜像配置错了，Composer 仍会尝试解析一个拼错的域名。典型错误：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer config -g repo.packagist https://mirrors.aliyun.com/composer（漏掉末尾/）→ 实际请求变成https://mirrors.aliyun.com/composer/packages.json，但正确路径是https://mirrors.aliyun.com/composer//packages.json（双斜杠不报错，但部分 CDN 会 404） - 用 HTTP 而非 HTTPS：
http://mirrors.tuna.tsinghua.edu.cn/composer/→ Composer 2.2+ 直接拒绝，报错Invalid repository type - 配置键名写错：
repos.packagist（旧版） vsrepo.packagist.org（新版），写错会导致静默失效，composer config -g repo.packagist输出为空或仍是packagist.org
CI 脚本里要清缓存 + 强制走新源，否则 DNS 改了也白搭
镜像换完，DNS 指定好了，但 composer install 还卡在 Downloading？大概率是旧缓存捣鬼。Composer 会优先读本地缓存里的元数据，而缓存里存的是旧源（packagist.org）的 URL 和哈希，它会先尝试连那个地址——哪怕你 DNS 已指向 8.8.8.8，它连的还是欧洲服务器。
CI 中必须三步并行：
- 运行
composer clear-cache - 删掉
vendor/和composer.lock（尤其不能保留旧 lock 文件，它含旧源哈希） - 用
composer install --no-cache --prefer-dist --no-dev重新拉取，确保第一字节就打向镜像站
最易被忽略的一点：DNS 设置和镜像配置必须在同一次构建流程中生效。单独改 DNS 不清缓存，或清了缓存却没换镜像，都会让提速努力归零。
