卡在“Resolving dependencies”是DNS解析失败或源不可达，非timeout问题；此时应验证DNS（如ping packagist.org）、更换系统DNS或换热点，而非调整http.timeout。
卡在 Resolving dependencies 是 DNS 或源不可达，不是 timeout 问题
看到 Resolving dependencies 停住不动，别急着改 http.timeout——这一步根本没发 HTTP 请求，纯粹是 Composer 在查本地缓存 + 解析 packagist.org 域名。如果 DNS 失败或域名被墙，它就卡在这儿干等，调任何超时参数都无效。
快速验证方式：
-
ping packagist.org：返回unknown host→ 换系统 DNS（比如设成8.8.8.8或114.114.114.114） -
curl -I https://packagist.org：卡住或报Failed to connect→ 防火墙/代理拦截，换手机热点一试便知 - 公司/学校网络常直接屏蔽
https://packagist.org和https://github.com，这不是你配错了，是策略层面不放行
卡在 Downloading https://... 才该调 http.timeout
这一行出现说明 Composer 已进入 HTTP 下载阶段，真正开始拉取 packages.json、dist 包元数据等。此时 http.timeout 才起作用——它控制单次 HTTP 请求从 DNS 查询、TLS 握手、首字节等待到 body 传输的总耗时。
默认值仅 60 秒，对国内网络或大包（如 laravel/framework）明显不够。实操建议：
- 全局设为
300～600：composer config --global http.timeout 600 - 临时生效更可靠：
COMPOSER_HTTP_TIMEOUT=600 composer install（注意 Linux/macOS 不能写export后再跑，某些 CI 会丢环境变量） - 别碰
http-basic.timeout：Composer v2 完全不读这个配置，写了也白写
卡在 Executing command 或 Cloning xxxxx 是子进程超时，得用 process-timeout 或环境变量
一旦看到 Executing command 或 Cloning，说明 Composer 正在调外部命令（如 git clone、unzip），这些操作不受 http.timeout 管控，而是由 process-timeout 或 COMPOSER_PROCESS_TIMEOUT 控制。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
常见陷阱：
-
process-timeout默认 300 秒（5 分钟），但 git clone 大仓库可能远超此限；建议设为1200（20 分钟）：composer config --global process-timeout 1200 - CI 环境中更推荐用环境变量：
COMPOSER_PROCESS_TIMEOUT=600 composer install，优先级高于配置文件，且避免被项目级composer.json覆盖 - 如果用了
--prefer-dist还卡在克隆，大概率是项目里硬写了repositories，直接覆盖了你的镜像源，必须删掉或改用 HTTPS 地址
镜像源配完没生效？先清缓存、再查作用域、最后验 URL 格式
很多人换了阿里云或清华源仍报错，不是镜像不行，而是缓存或配置层级捣鬼。
三步必做：
- 清缓存：
composer clear-cache，否则 Composer 可能继续读本地失效地址 - 确认作用域：运行
composer config -g repo.packagist（看全局）和composer config repo.packagist（看当前项目），项目级repositories优先级永远高于全局设置 - 检查 URL 末尾斜杠：清华源必须带
/，即https://mirrors.tuna.tsinghua.edu.cn/composer/，少一个就是 404；阿里云源则不需要
真正难搞的从来不是 timeout 数值本身，而是卡在哪一层你根本没看清——-vvv 输出的最后一行，才是唯一可信的线索。
