composer默认重试机制无效，需通过环境变量、shell封装和镜像源协同优化：--retries仅作用于dist包下载且不延长单次超时，应调高composer_network_timeout或http.timeout，并配合ipv4强制、指数退避脚本及--prefer-dist使用。
Composer 本身不提供自适应退避重试——它只有固定延迟、最多 3 次的简单重试，且不随网络状况动态调整。真要应对不稳定连接，必须绕过默认逻辑，用环境变量 + shell 封装 + 镜像源协同控制。
为什么 --retries=5 在弱网下基本没用
这个参数只影响 dist 包（zip/tar）下载，对 git clone 完全无效；更重要的是，它不延长单次请求等待时间。如果每次都在 CURL error 28（超时）下失败，重试 10 次也还是秒败。
-
--retries控制“重试轮数”，COMPOSER_NETWORK_TIMEOUT或http.timeout才决定“每轮能忍多久” - 旧版本（如 2.1.x）会静默忽略
--retries，实际仍是默认 3 次 - 私有包没提供 dist 时，Composer 自动 fallback 到 source，此时
--retries不生效
必须调高的两个超时值
国内常见卡在 Downloading (0%)，本质是 TLS 握手或首字节等待超时。默认 http.timeout=60 在高延迟链路上根本不够用。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 临时生效：
COMPOSER_NETWORK_TIMEOUT=300 composer install（单位秒，覆盖http.timeout） - 永久生效：
composer config -g http.timeout 300（注意不是http-timeout，那是旧别名） - 仍失败？加
CURL_IPRESOLVE=4强制走 IPv4，避开某些 ISP 的 IPv6 不稳定问题
shell 封装实现可控的指数退避
Composer 没内置指数退避，但你可以用 shell 实现：每次失败后清状态、等更久、再试。这比依赖它自身逻辑可靠得多。
for i in {1..3}; do
rm -rf vendor/ composer.lock
composer install --no-interaction --prefer-dist && break
sleep $((i * 10))
done
-
--prefer-dist强制走 zip 包，跳过易被拦截的git clone - 每次失败都
rm -rf vendor/ composer.lock，避免残留损坏文件导致下一次校验失败（比如filemtime(): stat failed） - 不要只靠
composer install || sleep 5 && composer install——没清缓存和临时文件，大概率重复失败
镜像源配置 ≠ 自动容灾 fallback
Composer 的 repositories 数组不是容灾列表，而是元数据匹配顺序表。它不会因为第一个源超时就自动切到第二个。
- 只有当首个源对某包返回明确
404，才会查下一个源是否声明了该包 -
timeout、502、503、DNS 失败等，直接报错退出，绝不会 fallback - 验证镜像是否生效：
composer config -l | grep repos.packagist，输出应为阿里云地址，而非https://packagist.org
真正容易被忽略的是：重试只作用于单次 HTTP 请求，它不解决镜像元数据不同步、DNS 解析失败、TLS 握手卡死这类前置问题。如果你看到日志里反复出现 Failed to decode response 或 Invalid package information，那大概率不是重试能救的——得换源、清缓存、或等镜像同步。
