唯一有效的项目级超时设置是composer.json中config下"process-timeout": 900（整数无引号），控制git clone等子进程，默认300秒；http.timeout不支持写入该文件，需用环境变量或命令行参数。
在 composer.json 的 config 里加 process-timeout
项目级超时设置唯一有效的方式，是在 composer.json 的 config 节点下写 "process-timeout": 900。这个值控制 git clone、unzip、php -r 等子进程执行上限，默认 300 秒，CI 中大项目极易触发。
- 必须是整数，不能加引号：
"process-timeout": 900✅，"process-timeout": "900"❌ - 字段名严格为
process-timeout；timeout、http-timeout、config.timeout全部无效，Composer 会静默忽略 - 改完后建议运行
composer dump-autoload -o，避免 autoload 错误掩盖真实超时问题 - 该配置随项目提交，CI/CD 环境自动继承，无需额外操作
别把 http.timeout 和 process-timeout 混在一起设
http.timeout 不支持写进 composer.json 的 config 段——它早已被废弃。HTTP 层超时（比如卡在 Downloading https://）只能靠环境变量或命令行参数控制，和 composer.json 无关。
- 如果你看到错误含
cURL error 28或failed to open stream: Connection timed out，那是 HTTP 下载阶段卡住，process-timeout完全不起作用 - Composer 2.2+ 可用
--http-basic-timeout=300控制单次 HTTP 请求，但依然不能写进composer.json - PHP CLI 的
default_socket_timeout必须 ≥ 你设的 HTTP 超时值，否则底层 socket 会在 60 秒就断开（查法：php -i | grep default_socket_timeout）
验证配置是否生效最直接的方法
改完 composer.json 后，不要猜，直接用 composer config 命令确认：
- 查当前项目配置：
composer config process-timeout，有输出即生效，无输出说明仍用默认 300 - 注意别错用成全局命令：
composer config -g process-timeout查的是用户级配置，和项目无关 - 如果输出是字符串而非数字（如
"900"），说明你误加了引号，需手动删掉再保存
为什么设了 process-timeout 还报超时？常见漏点
多数“设了没用”不是配置失败，而是被其他层级截断了：
- CI runner 本身有硬性超时（如 GitLab 自建 runner 设了 20 分钟），比 Composer 的
process-timeout更早触发 - PHP 的
max_execution_time被disable_functions禁用，导致脚本类钩子（如post-install-cmd）根本跑不到超时判断就报错 - 内存不足（
memory_limit小于 1.5G）时，Composer update 解析锁文件可能先 OOM，再被误判为超时 - 用了
--no-dev但脚本里又调了phpstan这类 dev-only 工具，实际没装上，脚本执行失败被当成超时
composer.json 的 config.process-timeout 字段，且必须是未加引号的整数。其他所有地方写的 timeout 都不参与该项目的子进程超时判定。 
