Composer install 失败后不自动重试会出问题，因为中断会导致元数据（如 packagist 索引、installed.json）处于半写入状态，引发 TransportException 或 foreach() 错误；Composer 不自动清理或回滚损坏数据。
为什么 composer install 失败后不自动重试会出问题
因为 Composer 的元数据（如 packagist.org 的包索引、vendor/composer/installed.json）在安装中断时可能处于半写入状态，下次直接重试容易触发 Composer\Downloader\TransportException 或 Invalid argument supplied for foreach() 这类非明确错误。关键不是网络抖动本身，而是元数据损坏后 Composer 不会自动清理或回滚。
用 shell 脚本包装 composer install 实现可控重试
别依赖 Composer 自身的 --no-interaction 或 --prefer-dist 来“防失败”，它们不解决元数据残留问题。必须在每次重试前做两件事：删掉 vendor/ 和 composer.lock 的临时残留（如 composer.lock~），再清空 Composer 缓存中可能卡住的包版本快照。
- 用
rm -rf vendor/ composer.lock~清理本地污染（composer.lock本身要保留，它是可信源） - 加
composer clear-cache防止缓存里存着损坏的packages.json副本 - 限制重试次数（比如最多 3 次），避免无限循环卡死 CI 流水线
- 每次重试间隔 2 秒，用
sleep 2，别用0.5—— Packagist 的 CDN 刷新有延迟
示例脚本核心逻辑：
for i in $(seq 1 3); do
if composer install --no-interaction --prefer-dist; then
exit 0
fi
rm -rf vendor/ composer.lock~
composer clear-cache
sleep 2
done
exit 1
composer install 在 CI 环境里重试的隐藏陷阱
很多团队在 GitHub Actions 或 GitLab CI 里直接套用本地脚本，结果发现重试没效果 —— 因为默认的 composer install 会读取 COMPOSER_CACHE_DIR 环境变量指向的缓存路径，而 CI runner 往往复用同一缓存目录，导致损坏的元数据反复被加载。
- CI 中务必显式设置
COMPOSER_CACHE_DIR=/tmp/composer-cache-$RANDOM，让每次运行隔离缓存 - 不要用
composer update替代install来“修复”，它会改写composer.lock，破坏可重现性 - 如果项目用了私有仓库（如 Satis 或 Private Packagist），重试前还得确认
auth.json没被并发写入损坏，建议用cp auth.json.example auth.json初始化
真正需要重试的场景其实很窄
90% 的所谓“网络失败”其实是 DNS 解析超时或 TLS 握手失败，这类问题重试 1–2 次就该放弃；剩下 10% 是 Packagist 元数据服务短暂不可用（返回 503），这时重试才有效。但要注意：如果连续两次都卡在同一个包（比如 monolog/monolog），大概率是该包的 dist ZIP 文件被 CDN 缓存了损坏副本，此时该换镜像源而不是加更多重试。
最常被忽略的一点：重试逻辑必须和退出码绑定 —— composer install 失败时返回非 0 码，但某些插件（如 hirak/prestissimo）异常退出可能返回 0，得用 set -o pipefail 和检查 stderr 是否含 ERROR 字样来兜底。
