生产环境必须显式设process-timeout，因默认300秒在私有仓库、大包、CI带宽受限等场景下极易触发ProcessTimedOutException；该值对每个子进程单独计时，非总耗时，建议CI设1800秒并配合镜像源与内存配置。
生产环境必须显式设 process-timeout，且不能依赖默认值或临时命令行参数——否则 CI 流水线大概率在“Updating dependencies”阶段静默失败。
为什么生产环境的 timeout 不是可选项
Composer 默认 process-timeout 是 300 秒（5 分钟），但这个值在生产部署中几乎必然不够：私有 GitLab 响应慢、vendor 包含大体积二进制文件（如 laravel/sail）、CI 节点带宽受限、甚至只是 PHP 进程被系统 OOM killer 干掉，都会表现为“超时”，而错误日志里往往只显示 ProcessTimedOutException 或直接中断，没有具体哪一步卡住。
更麻烦的是：这个超时不是全局生效的单一计时器，而是对每个子进程（git clone、unzip、post-install 脚本）分别计时——所以你可能在拉取第 3 个包时就触发了超时，而非整个命令总耗时超标。
- CI 环境建议设为
1800（30 分钟），并配合平台级兜底（如 GitHub Actions 的timeout-minutes: 40） - 不推荐设为
0（禁用超时），一旦网络假死或镜像源不可用，任务会无限挂起，阻塞整个流水线 - 别信“本地能过，线上就该没问题”——生产环境的 I/O、DNS、SSH agent 配置和本地开发机完全不同
config.process-timeout 和 COMPOSER_PROCESS_TIMEOUT 怎么选
两者都有效，但优先级和适用场景不同：
-
config.process-timeout写在composer.json的config节点里，随代码提交，对所有执行该项目的机器生效，适合团队统一基线 -
COMPOSER_PROCESS_TIMEOUT是环境变量，优先级更高，适合 CI/CD 中按环境覆盖（比如 staging 设 900，prod 设 1800） - 错误写法：
composer install --timeout 600（漏等号）会被静默忽略；正确写法必须带=：composer install --timeout=600 - 环境变量在 Docker 中要显式
ENV COMPOSER_PROCESS_TIMEOUT=1800，不能只靠docker run -e传入，否则某些基础镜像会丢弃
常见“伪超时”陷阱：别只调 timeout 就以为万事大吉
很多报错看着像超时，实际根本不是时间问题：
- 内存不足：PHP
memory_limit小于 1.5G 时，composer update在解析锁文件阶段就可能 OOM，表现和超时一模一样 - Git 仓库卡住：用了
"type": "vcs"的包，每次git clone都计入超时——先手动git clone测试 SSH 连通性、代理配置、是否需要git config --global url."https://".insteadOf git:// - 镜像源失效：国内项目没切阿里云镜像，
--timeout=3600也救不了连不上packagist.org的情况；执行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/才是前提 - autoload 生成阻塞：
Generating autoload files卡住，大概率是 vendor 下 symlink 过多或 NTFS/WSL2 文件系统 I/O 慢，和 timeout 设置无关
真正关键的不是“设多大”，而是“谁来设、在哪设、设完怎么验证”。上线前务必在目标环境跑一次完整 composer install --no-dev --optimize-autoloader，并观察真实耗时——别让第一次部署成为超时排查现场。
