CI中Composer安装超时应通过调优重试超时、启用国内镜像与缓存、分阶段执行及禁用高风险脚本来提升稳定性，稳比快重要。
在 CI 环境中运行 composer install 偶尔超时，通常不是网络完全不通，而是因下载慢、重试机制不足或并发策略不合理导致的“假性失败”。关键在于让 Composer 更稳定、更适应 CI 的不可靠网络环境。
启用并调优 Composer 的重试与超时参数
Composer 默认重试次数少（2次）、单次超时短（300秒），CI 中遇到临时抖动就容易失败。建议显式增强容错能力：
- 加
--prefer-dist强制走压缩包安装（比 git clone 快且稳定） - 设
--no-interaction --no-progress避免交互和进度条干扰日志 - 用环境变量提升鲁棒性：
COMPOSER_PROCESS_TIMEOUT=2000（全局命令执行超时）COMPOSER_AUTH={"github-oauth": {"github.com": "xxx"}}（避免因未登录 GitHub 触发限流）
使用国内镜像源 + 启用缓存目录
CI 每次都是干净环境，不缓存 vendor 和 zip 包会反复下载。推荐组合方案：
- 切换镜像源：运行
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 挂载或复用 Composer 全局缓存目录（如 GitHub Actions 的
$HOME/.composer/cache），避免重复下载相同 zip 包 - 若用自建私有包，确保镜像源配置正确，避免回源超时
分阶段执行：先 install 再 build
把依赖安装和构建逻辑拆开，能更快定位是哪步卡住，也方便跳过已缓存的步骤：
- 第一阶段只跑
composer install --no-dev --classmap-authoritative（生产模式，更轻更快） - 第二阶段再跑测试或打包命令，不重复装依赖
- 某些 CI（如 GitLab CI）可利用
cache:关键字缓存vendor/目录（注意排除 dev-only 包冲突）
降级或绕过高风险操作
某些插件或脚本（如 hirak/prestissimo 已废弃、某些 post-install-cmd）可能引发不稳定：
- CI 中禁用所有自定义脚本：
composer install --no-scripts，后续按需单独触发 - 移除过时插件（特别是并行下载类），Composer 2.2+ 原生支持并发，无需额外扩展
- 若项目含大量私有 repo，考虑提前 fetch 或用
composer global require cweagans/composer-patches类工具预处理
基本上就这些。不复杂但容易忽略——重点是关掉干扰项、用好缓存、给足重试时间。CI 不是本地机器，稳比快重要。
