答案是composer不管理dns，需从系统、php/curl层入手：清系统dns缓存、换稳定dns（如8.8.8.8）、禁用ipv6（composer_no_ipv6=1），再用curl和dig验证解析是否正常。
Composer 本身不管理 DNS，所谓“刷新 Composer 的 DNS”其实是解决它背后 PHP/curl 系统层的 DNS 缓存或解析失败问题。直接改 Composer 配置没用，得从操作系统、PHP 运行时和网络链路入手。
为什么 composer update 看似卡在 DNS
现象是 composer update 停在 “Resolving dependencies” 或日志里反复出现 Failed to decode response: Failed to open https://packagist.org/packages.json，但 ping packagist.org 又通——这基本是 DNS 解析返回了错误 IP、缓存了过期记录，或系统默认尝试 IPv6 失败后 fallback 慢（常卡 2–3 秒/请求，叠加几十个包就几分钟无响应）。
必须执行的三步系统级 DNS 清理
不是 Composer 命令能解决的，得动系统和 PHP 层：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 清系统 DNS 缓存：Windows 执行
ipconfig /flushdns；macOS 执行sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder；Linux（systemd-resolved）执行sudo systemd-resolve --flush-caches - 换稳定 DNS：把网卡 DNS 改成
8.8.8.8或1.1.1.1，避免 ISP 提供的 DNS 污染或超时 - 禁用 IPv6（最立竿见影）：临时关闭系统 IPv6，或让 Composer 绕过它——加环境变量
COMPOSER_NO_IPV6=1再运行命令，比如COMPOSER_NO_IPV6=1 composer update
验证是否真解决了 DNS 问题
别信 Composer 日志，用底层命令交叉验证：
-
curl -v https://packagist.org 2>&1 | grep "Connected to"—— 如果看到 IPv6 地址（如2a03:2880:）且后续卡住，就是 IPv6 fallback 在拖慢 -
dig packagist.org +short或nslookup packagist.org 8.8.8.8—— 看返回的 IP 是否合理（官方源通常在欧洲，IP 段应是137.74.169.x或类似），如果返回127.0.0.1或私有地址，说明 hosts 被污染或 DNS 劫持 - 在 Docker 容器里跑
composer update卡住？大概率是容器 DNS 配置继承了宿主机但没生效，要显式加--dns 8.8.8.8启动
镜像源配置不能替代 DNS 修复
很多人配了阿里云镜像还卡，是因为：
- 镜像 URL 写错（比如少末尾
/，导致 404 后 fallback 到默认源） - 项目级
composer.json里硬写了"repositories"，覆盖了全局镜像 - DNS 已坏，连
mirrors.aliyun.com都解析不了——这时换镜像毫无意义
真正卡点往往藏在 curl 层、glibc DNS 解析器或容器网络栈里，而不是 Composer 自己的逻辑。先让 curl -I https://mirrors.aliyun.com/composer/packages.json 秒回，再跑 Composer 才有意义。
