composer.json中config.process-timeout是唯一通用配置项，值为整数（如"process-timeout": 900），适用于Composer 1.x和2.x，控制install/update/require等命令的子进程超时，随项目提交并被CI/CD自动继承。
composer.json 里 config.process-timeout 是唯一通用配置项
Composer 1.x 和 2.x 都只认 process-timeout 这个键，其他如 timeout、http-timeout、default-timeout 全部被静默忽略。值必须是整数，不能加引号："process-timeout": 900 ✅，"process-timeout": "900" ❌。
这个字段写在 composer.json 的 config 节点下，随项目提交，CI/CD 环境自动继承，无需额外操作。它对 composer install、composer update、composer require 全部生效。
注意：Composer 2.2+ 开始支持 http-client.timeout（单位秒），但仅限 HTTP 请求层，不覆盖 process-level 超时；且 1.x 完全不识别，跨版本迁移时不要依赖它。
全局配置要按 Composer 版本分别设置
用 composer config -g 设置的全局超时，实际写入的是 ~/.composer/config.json，而 Composer 1.x 和 2.x 对该文件的解析逻辑略有差异：
- Composer 1.x 会读取
process-timeout并应用到所有命令 - Composer 2.x 同样读取
process-timeout，但若同时存在http-client.timeout，后者仅影响下载阶段
所以迁移时别指望“一次配置，两头生效”。如果你在旧服务器用 Composer 1.x 配了全局 process-timeout，换到新服务器用 Composer 2.x，仍需重新运行：
composer config -g process-timeout 1200
否则新环境可能沿用旧配置（如果复用了 ~/.composer/config.json），也可能压根没配——取决于你是否手动迁移了该文件。
命令行临时覆盖优先级最高，但不跨版本持久
--timeout 参数在所有 Composer 版本中都可用，例如：
composer install --timeout=1800
它会覆盖 composer.json 和全局配置，且 1.x / 2.x 行为一致。但问题在于：它只对当次命令有效，无法“迁移”——你没法把一个命令行参数变成下次运行的默认行为。
容易踩的坑：
- 误以为
composer install --timeout=1800执行完后，后续composer update也会继承这个值（不会） - 在 CI 脚本里只写了一次
--timeout，但多个命令分散在不同步骤，漏掉某处就可能超时失败 - Composer 2.5+ 开始，
--timeout仅控制 process 层，HTTP 超时需另配--http-timeout（1.x 不支持该参数，加了会报错）
升级 Composer 版本后务必验证超时是否生效
Composer 2.x 默认 process-timeout 是 300 秒，比 1.x 的 600 秒更激进。如果你从 1.x 升到 2.x，又没在 composer.json 或全局配置里显式设值，很可能突然遇到 ProcessTimedOutException。
验证方法很简单：
- 删掉
vendor/和composer.lock - 运行
php -d memory_limit=-1 $(which composer) install --no-dev -v - 观察日志里是否出现
Running update with --no-install后长时间卡住，再报 timeout 错误
真正容易被忽略的是：超时配置不是孤立的。它和 platform 设置、插件启用状态、甚至 PHP 的 max_execution_time 都可能叠加影响——比如某个 post-install-cmd 脚本本身耗时很长，process-timeout 控制不了它，得单独优化脚本或禁用插件。
