dns慢会卡住composer并发拉取，因curl multi批量请求中任一域名dns解析延迟（如容器默认127.0.0.11平均150ms+）将阻塞整批请求，默认3秒超时后才释放；docker需显式指定--dns 8.8.8.8或114.114.114.114，否则宿主机dns不透传，换镜像源无效。
为什么DNS慢会卡住Composer并发拉取
Composer本身不直接并发，但像composer-plugin-parallel-downloader这类插件依赖cURL multi批量发请求——一旦DNS解析卡在某个域名上，整批并发请求就会被阻塞。实测显示，容器或CI环境中默认DNS（如127.0.0.11）平均解析延迟达150ms以上，而并发10个请求时，哪怕仅1个域名慢，其他9个也得等它超时（默认3s）才能继续。
Docker内必须显式指定DNS服务器
宿主机DNS配置不会自动透传到容器，尤其在使用docker-compose或Kubernetes时，/etc/resolv.conf常被覆盖为低效的转发链。不改DNS，换再快的镜像源也白搭。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 启动容器时加
--dns 8.8.8.8 --dns 114.114.114.114（后者是国内响应最快的公共DNS） - 全局配置Docker daemon：编辑
/etc/docker/daemon.json，加入"dns": ["8.8.8.8", "114.114.114.114"]，然后sudo systemctl restart docker - CI环境（如GitHub Actions）中，在
run步骤前加echo "nameserver 114.114.114.114" | sudo tee /etc/resolv.conf
验证DNS是否真正生效
别只看composer config -g repo.packagist，那只是源地址，不是解析行为。要确认DNS优化起效，得看实际请求日志：
- 加
-vvv运行composer install，搜索Resolving packages...和Downloading https://之间的耗时，若超过200ms，大概率是DNS问题 - 进容器执行
time nslookup mirrors.aliyun.com，多次测试应稳定在 - 若用自建镜像源（如公司内网
https://repo.internal.com/composer/），确保该域名已提前在DNS服务器中完成A记录预解析，避免首次拉取时集体卡顿
并发数与DNS能力必须匹配
http-max-concurrent-downloads设太高反而更慢——如果DNS服务器本身并发解析能力弱（比如dnsmasq默认限制5并发），设成10会导致大量请求排队等待解析。这不是Composer的问题，是底层设施瓶颈。
- 推荐值：DNS用
114.114.114.114时，设composer config -g http-max-concurrent-downloads 8 - 若DNS换成
cloudflare-dns.com（1.1.1.1），可尝试10，但需配合COMPOSER_PROCESS_TIMEOUT=3000防超时 - 关键点：并发下载数 ≠ 并发DNS请求数。每个包元数据+ZIP下载各需一次DNS解析，所以实际DNS并发压力是设置值的2倍
composer.json里写几行配置，而在容器网络栈最底下那层/etc/resolv.conf是否干净、可靠、低延迟。
