cURL error 28触发后Composer仅对单次HTTP请求自动重试最多3次，不重跑整个install流程；重试仅作用于dist包下载，且需Composer ≥2.2支持，对git clone、元数据拉取或解压阶段无效。
Composer install报错cURL error 28后重试是否自动生效
不自动重试失败的整个命令，只对单次HTTP请求重试——也就是说，cURL error 28（Operation timed out）触发后，Composer会按默认策略重试该请求最多3次，但不会重新跑完整个install流程。
关键点在于：这个重试只发生在下载单个dist包（如.zip）时，且仅限于可恢复错误。如果超时发生在元数据拉取（packages.json）、git clone、或解压阶段，重试机制不介入。
-
cURL error 28属于默认重试范围，但前提是它由CURLOPT_TIMEOUT触发，而非CURLOPT_CONNECTTIMEOUT（后者超时后通常不重试） - 重试间隔是渐进的：第2次延迟100ms，第3次起延迟500ms，代码在
CurlDownloader.php里硬编码 - 若重试3次全失败，Composer直接抛出错误，不再尝试其他镜像或降级路径
为什么--retries=5没用，还是秒报错
两个常见原因：版本不支持，或参数作用域错配。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
--retries仅在Composer ≥2.2中有效；2.1.x及更早版本会静默忽略该参数，实际仍用默认3次 -
--retries只影响dist包下载，对git clone完全无效——如果你的包配置了"source"类型，调再多次也没用 - 它控制“重试次数”，不延长单次等待时间；真正卡住的往往是
http-basic-timeout（默认60秒）太短，导致首字节都收不到就超时 - 临时生效要写全：
composer install --retries=5 --http-basic-timeout=300，缺一不可
重试失败后该手动做什么
别盲目再跑composer install——残留状态决定能否续上。
- 运行
composer install --dry-run：如果大量显示Skipped，说明vendor和缓存一致，可安全重试 - 如果看到
Installing或报Invalid argument supplied for foreach()，基本是installed.json写到一半中断，必须删掉vendor/和composer.lock重来 - ZIP下载中断后，Composer会自动清理临时文件，重试=全新下载；但若本地缓存里已有损坏包，需加
--no-cache绕过 - CI环境建议始终加
--prefer-dist --no-interaction --no-scripts，避免钩子和交互拖慢流程
真正卡住时，重试不是第一解法
当cURL error 28反复出现，优先排查源头而非调参数。
- 确认镜像URL结尾有斜杠：
https://mirrors.aliyun.com/composer/，少斜杠会导致404然后无限重试 - 用
curl -v https://mirrors.aliyun.com/composer/packages.json直测，卡在* Connected to后不动，大概率是DNS污染或代理干扰 - 公司/校园网常劫持HTTPS，尝试
--resolve强制IP：curl --resolve mirrors.aliyun.com:443:114.114.114.114 -v https://... - CI流水线里，
process-timeout设再大也救不了没挂载缓存——必须显式配置$HOME/.composer/cache缓存复用
