应修改composer.json中config节点的process-timeout字段为整数（如900），该配置项目级生效、可提交、无需额外命令；注意字段名必须为process-timeout，其他如timeout或http-timeout会被静默忽略。
直接改 composer.json 的 process-timeout 最快最稳
项目级超时配置，改完立刻生效，无需额外命令或环境变量。打开项目根目录的 composer.json，在 config 节点里加一行：
"config": {
"process-timeout": 900
}
这个值必须是整数、不带引号，且只认 process-timeout——timeout、http-timeout 等字段名 Composer 会静默忽略。改完别忘了运行 composer dump-autoload -o，避免 autoload 错误掩盖真实超时问题。
--timeout= 命令行参数只对当前命令有效
临时延长主流程熔断阈值，比如 CI 中某次 composer update 卡住，不想改配置文件时用它：
-
composer install --timeout=1800✅ 必须带等号，值为整数秒 -
composer install --timeout 1800❌ 无等号会被完全忽略 - 它管的是整个命令生命周期：依赖解析 + 下载 + 解压 + 执行脚本，但不管单个 HTTP 请求或子进程（如
git clone） - 如果卡在
Downloading https://阶段，仅设这个不够，还得配--http-basic-timeout=300（Composer 2.2+）
CI/CD 里优先用环境变量 COMPOSER_PROCESS_TIMEOUT
容器每次启动都重置全局配置，composer config -g 在 CI 中不可靠；环境变量优先级最高，且不依赖写入权限：
- GitHub Actions：
COMPOSER_PROCESS_TIMEOUT: 1800 - GitLab CI：
variables: { COMPOSER_PROCESS_TIMEOUT: "1800" } - Docker 启动时：
-e COMPOSER_PROCESS_TIMEOUT=1800 - 设为
0表示禁用超时，但风险高：一旦某条git clone卡死，job 就无限挂起
自定义脚本超时不是 Composer 控的，得调 PHP 设置
像 post-install-cmd 这类脚本由 PHP 直接执行，和 process-timeout 无关，受 PHP 自身 max_execution_time 限制：
- 临时方案：
php -d max_execution_time=0 composer install - 脚本内主动控制：
set_time_limit(0)，但得确保在脚本入口尽早调用 - CI 中常见坑：PHP 的
max_execution_time被disable_functions禁用，或memory_limit不足导致 OOM，被误判成超时
真正容易被忽略的是层级叠加：环境变量 > 配置文件 > 命令行参数，但 --timeout= 只覆盖主流程，不覆盖子进程或 PHP 脚本；卡在哪一环，就得调对应那一层的开关。
