Composer超时需调高process-timeout（如3600秒），优先换国内镜像源并清缓存；CI中用--timeout=7200+--no-interaction，避免update上生产；超时设超7200秒将被强制回退至默认300秒。
composer install 或 update 卡住、报 timeout 错误
默认情况下，composer 对网络请求设了 300 秒（5 分钟）超时限制，遇到源慢、包大或网络抖动，很容易触发 Connection timed out 或 Failed to decode response。这不是你本地环境坏了，是它等不及了。
- 最直接的解法是调高超时阈值，用
--timeout参数临时覆盖：composer install --timeout=3600（单位是秒，这里设为 1 小时） - 如果频繁操作，建议全局改配置，避免每次输参数：
composer config -g process-timeout 3600 - 注意：
process-timeout控制的是整个命令生命周期（含脚本执行），不是单个 HTTP 请求；真正影响下载的是http.timeout，但 Composer 2.2+ 已将其合并进process-timeout，无需单独设
用了 --timeout 还超时？可能是源或 DNS 问题
加了超时时间仍失败，大概率不是“等不够久”，而是根本连不上或响应异常。这时候得换思路：
- 先试
composer clear-cache，缓存损坏会导致反复重试失败 - 检查当前源：
composer config repo.packagist.org，国内用户强烈建议切到阿里云镜像：composer config -g repo.packagist.org https://mirrors.aliyun.com/composer/ - DNS 解析慢也会拖垮连接，可临时在终端加
export COMPOSER_HOME=~/.composer并确认 hosts 是否有异常条目；更简单的是直接加--no-plugins排除插件干扰
CI/CD 环境下 composer install 超时怎么稳住
自动化流程里不能靠人盯屏重试，超时必须可预期、可收敛：
- GitLab CI 或 GitHub Actions 中，务必显式声明超时：
composer install --no-interaction --no-progress --timeout=7200 - 避免用
composer update上生产，它会重新解析依赖树，耗时远高于install；CI 中应基于已提交的composer.lock执行install - 某些 Docker 基础镜像自带低 timeout 配置，构建前先运行
composer config -g process-timeout 7200再装包，比后期修复更可靠
超时设置不是越大越好
设成 24 小时看似保险，实际会让失败更难定位——你不知道是真卡住，还是早就该报错退出了。
-
process-timeout超过 7200（2 小时）后，Composer 会主动忽略该值，强制回退到默认 300 秒，这是硬编码限制 - 真正慢的环节常是 post-install-cmd 脚本（比如 npm run build），这类应单独优化或拆出 CI 步骤，而不是靠拉长总 timeout
- 如果你发现即使设了 3600 秒，每次都在 3590 秒左右断，那八成是中间某个远程服务（如 GitHub API 限流）在掐你，得查日志里的具体
curl错误码
