process-timeout 是 Composer 限制单个外部进程（如 git clone、unzip）最长运行时间的配置，默认300秒；超时后主动终止子进程，非网络或命令错误。
process-timeout 是什么，为什么它会中断你的 Composer 命令
process-timeout 是 Composer 用来限制单个外部进程（比如 git clone、unzip 或脚本执行）最长运行时间的配置项，默认值是 300 秒（5 分钟）。当某个包安装过程中需要拉取大仓库、解压臃肿的 dist 包，或执行耗时的 post-install-cmd 脚本时，就容易触发超时，报错类似：
Process timeout exceeded for ... command
这不是网络问题，也不是命令写错了，而是 Composer 主动 kill 掉了还在跑的子进程。
全局设置 process-timeout 的两种可靠方式
推荐优先用命令行参数覆盖，避免污染全局配置；若需长期生效再改配置文件。
- 临时生效（仅本次命令）：在任意
composer install或composer update后加--process-timeout=1200（单位秒），例如：composer install --process-timeout=1200 - 永久生效（当前用户）：运行
composer config --global process-timeout 1200，该值会写入~/.composer/config.json - 项目级覆盖（不推荐滥用）：在项目根目录
composer.json里加："config": { "process-timeout": 1200 }—— 注意这会随代码提交，可能影响他人环境
设成 0 表示永不超时？小心副作用
把 process-timeout 设为 0 确实禁用超时机制，但不等于“更安全”。一旦某个脚本卡死（比如无限循环的 post-autoload-dump）、或 Git 服务无响应却没断连，Composer 就会一直挂起，阻塞 CI 流水线或本地终端，且无法被 Ctrl+C 干净中断。
- CI/CD 环境建议显式设为合理上限（如
1800即 30 分钟），而非0 - 开发机可设高些（如
900），但别盲目设0 - 如果频繁遇到超时，优先检查是不是某包的
scripts或installers本身有性能缺陷，而不是一味调高 timeout
和 timeout、github-oauth 等其他超时配置的区别
process-timeout 只管「子进程执行」，和下面这些互不干扰：
-
timeout（已弃用）：旧版 Composer 用于 HTTP 请求超时，新版统一由http-basic和底层 Guzzle 控制 -
github-oauth：解决 GitHub API 限流，跟进程执行无关 -
cache-dir或fxp-asset：影响下载路径或包源代理，不改变单进程生命周期
真正要排查脚本卡住，得看 composer install -v 输出的最后一段命令，确认是哪个具体进程被 kill，再针对性优化或调 timeout。
