真正降低重试成本的关键是精准控制超时层级、避免卡死，并清除中断后残留的破损文件，而非缩短timeout；需区分http-basic-timeout（管http请求）与process-timeout（管git/unzip等子进程），并手动清理vendor/autoload.php、vendor/composer/等残留，再执行dump-autoload和install，必要时clear-cache。

不能靠缩短 timeout 来降低重试成本——它只会让失败更快发生，且残留状态更难清理。 真正减少重试代价的，是精准控制超时层级、避免卡死、并清除中断后残留的破损文件。

卡在 Downloading https:// 时该调 http-basic-timeout 还是 process-timeout

看错误最后一行：

• 如果停在 Downloading https://mirrors.aliyun.com/...，说明是单次 HTTP 请求卡住（DNS/TLS/首字节/传输全阶段），必须调 http-basic-timeout（Composer 2.2+）或旧版的 http.timeout
• 如果报 [RuntimeException] The process "git clone ..." exceeded the timeout，才是 process-timeout 生效——它管的是 git、unzip、post-install-cmd 这类子进程
• 两者互不覆盖：只改 http-basic-timeout，但 git clone 卡住 10 分钟，照样失败；只加 process-timeout，但单个 ZIP 下载 60 秒就断连，也救不了

为什么设小 timeout 反而拉高重试成本

Composer 没有断点续传。中断后会留下：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 截断的 ZIP 包（校验失败但不自动删）
• 破损的 vendor/composer/installed.json
• 半生成的 vendor/autoload.php（删整个 vendor/ 会导致后续命令直接报错）
• 这些文件不会被下次 composer install 覆盖，而是触发 Failed to extract 或 Content-Length mismatch

你越早中断，越可能卡在“看似下载完成、实则校验不过”的中间态——比等满 5 分钟再失败更难诊断。

真正降低重试成本的操作清单

不是调小 timeout，而是让每次失败后恢复更快、干扰更少：

• 中断后先清理关键残留：rm vendor/autoload.php && rm -rf vendor/composer/（别删整个 vendor/）
• 再跑 composer dump-autoload && composer install，跳过 autoload 重建失败环节
• 若仍报校验错误，说明缓存已坏，必须 composer clear-cache（镜像源配置后也得清）
• CI 环境中，用 COMPOSER_PROCESS_TIMEOUT=1800 + COMPOSER_HTTP_BASIC_TIMEOUT=300 配合阿里云镜像，比反复重试 30 秒 timeout 更省时间

最麻烦的从来不是“等多久”，而是那些静默留在 vendor/ 里、不报错但永远不工作的破损包文件——它们不会自己消失，也不会被 --force 清掉。