卡在Resolving dependencies是DNS或镜像配置问题，http.timeout无效；停在Downloading才需调http.timeout；停在Executing command则应调process-timeout或Git配置；必须用-vvv定位卡点，并通过dig/ping实测DNS。
Composer 的 http.timeout 对 DNS 问题完全无效——卡在 Resolving dependencies 阶段时，它根本没发 HTTP 请求，调 timeout 只是白等。
看 -vvv 输出最后一行，定位卡点在哪一层
运行 composer update -vvv 或 composer install -vvv，盯住终端最后几行：
- 停在
Resolving dependencies→ 是 DNS 解析失败或镜像未生效，http.timeout和process-timeout都不生效 - 停在
Downloading https://...→ 才轮到http.timeout起作用 - 停在
Executing command（比如git clone）→ 这是子进程超时，得调process-timeout或 Git 自身配置
用 dig 和 ping 直接验证 DNS 是否通
别信“应该能解析”，必须实测：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 跑
dig packagist.org @114.114.114.114 +short，看是否返回 IPv4 地址；若超时或无输出，说明该 DNS 不可用 - 跑
ping -c 1 packagist.org，返回unknown host就是 DNS 失败，不是网络慢，是根本没解析出来 - 改完 DNS 后，
composer clear-cache会触发大量 DNS 查询，这才是最严苛的测试——如果它卡在Loading composer repositories，90% 就是 DNS 问题
镜像源配了也不生效？检查三个隐藏优先级陷阱
即使你执行了 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，也可能被以下情况覆盖：
- 项目根目录
composer.json中存在"repositories"字段（哪怕只是{}）→ 它会直接忽略全局镜像 - 全局配置里写的是
repos.packagist（旧键名），但 Composer ≥ 2.2 要求用repo.packagist（少个s） - 清华镜像 URL 必须带末尾斜杠：
https://mirrors.tuna.tsinghua.edu.cn/composer/，漏掉就 404，且错误日志里不会明说
IPv6 fallback 是最隐蔽的“假性超时”
Composer 默认先试 IPv6 地址，单次超时约 1–3 秒；拉 100 个包，就是几分钟卡住、无报错、-vvv 日志也看不出异常：
- 验证：运行
curl -v https://packagist.org 2>&1 | grep "Connected to"，若看到类似Connected to packagist.org (2a03:2880:...)后卡住，基本坐实 - 临时绕过：加
-4强制 IPv4：curl -4 -I https://packagist.org，秒开即确认 - 根治：Linux 下执行
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1；或在/etc/resolv.conf里把 IPv4 DNS 放在最前，避免系统返回 AAAA 记录
真正卡住的时候，往往不是配置写错了，而是你调的参数根本没打到问题层上——DNS 层的问题，得用 DNS 工具查，不是靠改 http.timeout 硬扛。
