Composer本身不管理DNS缓存，真正影响安装速度的是镜像配置（URL末尾必须带/）、本地缓存路径（需清cache/repo/及vendor/、lock文件）和ZIP包是否命中cache/files/目录。
Composer本身不管理DNS缓存，别配错地方
Composer 没有内置的 DNS 缓存机制，也不会读取或控制系统的 DNS 缓存大小。所谓“调大 DNS 缓存”是常见误解——你看到的重复安装变慢，90% 是因为 Composer 仍在反复请求 packagist.org 或 github.com，而根本原因通常是镜像没生效、缓存损坏，或 vendor/ 锁定了旧源。真正该动的是镜像配置和本地缓存路径，不是 DNS。
为什么改系统 DNS 缓存对 Composer 安装没用
即使你把系统 DNS 缓存设成 10000 条（如 systemd-resolved 的 CacheSize=10000），Composer 仍可能卡在 Downloading https://codeload.github.com/ —— 因为它压根不走系统 DNS 缓存，而是依赖 PHP 的 curl 或 stream 扩展发起 HTTP 请求，这些请求受操作系统底层 resolver 控制，但缓存命中与否对 Composer 安装耗时影响极小。更关键的是：
- Composer 元数据（
packages.json）只拉一次，之后靠本地cache/repo/； - ZIP 包下载走的是
cache/files/，命中就跳过网络请求； - 真正拖慢重复安装的，是
vendor/未清理 +composer.lock未更新 + 镜像 URL 少了个/导致静默 fallback。
真正让重复安装变快的三件事
想让第二次 composer install 秒出结果，盯住这三个点：
-
确认镜像 URL 末尾有斜杠：运行
composer config -g repo.packagist，输出必须含"url": "https://mirrors.aliyun.com/composer/"（注意结尾/），缺了就会拼错路径返回 404，然后自动退到 packagist.org； -
删干净再重试：仅
composer clear-cache不够，必须同步删掉vendor/、composer.lock和~/.composer/cache/repo/https---packagist.org/目录（否则元数据还是旧的）； -
验证 ZIP 缓存是否真被复用：执行
composer install -vvv，看到Writing /path/to/cache/files/monolog/monolog/2.10.0.0/monolog-monolog-xxx.zip且没出现Downloading行，才说明cache/files/命中成功。
公司网络下 DNS 问题怎么临时绕过
如果确实在内网遇到 Could not resolve host: packagist.org，说明是 DNS 解析失败，这时该做的是：
- 手动加 hosts 映射：
137.74.169.73 packagist.org（IP 以实时查询为准）； - 或给 Composer 配代理：
composer config -g http-proxy http://your-proxy:8080； - 或强制改系统 DNS（Linux/macOS 改
/etc/resolv.conf，Windows 改网络适配器设置），设为8.8.8.8或1.1.1.1； - 切记：改完要清系统 DNS 缓存（
sudo dscacheutil -flushcache或ipconfig /flushdns），并跑composer clear-cache同步 Composer 状态。
镜像 URL 少一个 /、composer.lock 没删、repo/ 子目录残留——这三处最容易被忽略，但只要有一个没处理，重复安装就永远快不起来。
