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 在高延迟链路上根本不够用。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 临时生效：
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，那大概率不是重试能救的——得换源、清缓存、或等镜像同步。
