Composer怎样通过本地DNS优化提速-composer-PHP中文网

composer不走本地dns，其dns解析由php curl完成，受系统dns影响；docker中需显式指定--dns，镜像url须含末尾斜杠和https，且换源后必须清缓存并删除vendor与composer.lock才能生效。

composer怎样通过本地dns优化提速

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 仍会尝试解析一个拼错的域名。典型错误：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(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（旧版） vs repo.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 中必须三步并行：