process-timeout触发中断是因为Composer内部用Symfony Process启动git clone等子进程时硬编码300秒超时，超时后主动kill进程；推荐设为600～1800秒，项目级配置优先级最高且最可靠。
process-timeout 必须调，否则 git clone 私有库、解压大包、执行 post-install-cmd 脚本时会无预警中断，错误里一定带 ProcessTimedOutException。
为什么 process-timeout 会触发中断？
Composer 内部用 Symfony Process 启动子进程（比如 git clone、unzip、php artisan optimize），硬编码了 300 秒超时逻辑。哪怕 PHP 脚本本身没设 set_time_limit(0)，Composer 也会在 5 分钟后主动 kill 进程。
常见卡点包括：
- 从内网 GitLab 克隆含大量 submodule 的仓库
- vendor 包体积超 200MB，解压耗时 >300 秒
- 自定义
post-install-cmd中调用数据库迁移或文件扫描 - WSL2 或 Docker 挂载卷场景下 I/O 延迟突增
怎么改 process-timeout 才真正生效？
三种方式优先级从高到低：临时 > 项目级 > 全局。但注意：composer config --global process-timeout 在 Composer ^2.2+ 已废弃，别信老教程。
- 项目级（推荐）：
composer config process-timeout 1800→ 写入当前composer.json的"config"段，只影响本项目 - 临时覆盖（CI 调试首选）：
COMPOSER_PROCESS_TIMEOUT=1800 composer install或composer update --process-timeout=1800 - 全局生效（慎用）：设环境变量
export COMPOSER_PROCESS_TIMEOUT=1800（Linux/macOS），Windows 需配置系统级变量
验证是否生效：composer config process-timeout 输出应为 1800；若为空，说明走默认值 300。
process-timeout 设多大才合理？
不是越大越好。它只控制子进程等待上限，不解决脚本本身效率问题。
- 设为
0表示禁用超时——不推荐生产环境使用，真遇到 Git 不可达或死循环会无限卡住 - 常规建议值：600～1800 秒（10～30 分钟）
- 超过 30 分钟的脚本，大概率该拆分或加进度反馈，而不是靠拉长 timeout
- 若稳定需要 25 分钟，说明依赖结构或脚本逻辑已偏离最佳实践
还要注意：这个值对 HTTP 请求完全无效，Downloading https:// 卡住得调 http-timeout，不是它。
为什么改了 process-timeout 还是超时？
常见失效原因：
- 项目
composer.json里已有"process-timeout": 300，你只运行了全局配置，它不会覆盖——Composer 优先读项目配置 - 脚本本身抛出的是
Allowed memory size exhausted或PHP Fatal Error，不是超时，调process-timeout没用，得调memory-limit - 某些旧版 Composer（process-timeout 支持不稳定，升级到 ^2.2 或更高更可靠
- CI 环境中，shell 层或 runner 自身有命令超时限制（如 GitHub Actions 默认 6h，GitLab CI 默认 1h），这时
process-timeout再大也白搭
真正卡死时，错误信息里一定包含 Symfony\Component\Process\Exception\ProcessTimedOutException，这是唯一判断依据。
