脚本执行超时由 PHP 的 max_execution_time 控制，而非 Composer；composer.json 中的 "timeout" 字段已废弃且仅影响 HTTP 下载。
脚本执行超时不是 Composer 控制的，得调 PHP 的 max_execution_time。 Composer 本身没有 script-timeout 或 post-install-cmd-timeout 这类配置项，所有自定义脚本（比如 post-install-cmd、pre-deploy）都由 PHP 进程直接执行，超时由 PHP 自身机制决定。
为什么 composer.json 里配 "timeout": 600 没用
很多人在 composer.json 的 config 段加 "timeout": 600，但这个字段早已废弃，且它只影响 HTTP 下载阶段（旧版等价于 http.timeout），对脚本完全无效。Composer 不会读取、也不会转发这个值给 PHP。
-
config.timeout是历史残留字段，2026 年所有稳定版 Composer 都忽略它 - 真正生效的是 PHP CLI 的
max_execution_timeini 设置 - 错误日志里若出现
PHP Fatal error: Maximum execution time of 300 seconds exceeded，就是它在报错
临时改脚本超时：用 php -d 最可靠
在运行 composer install 或 composer run-script 前，显式覆盖 PHP 执行时限：
- 不限制：
php -d max_execution_time=0 composer install - 设为 10 分钟：
php -d max_execution_time=600 composer run-script post-build - CI/CD 中推荐写死，避免依赖系统默认值（很多镜像默认是 30 秒或 60 秒）
注意：max_execution_time 在 php.ini 中若被 disable_functions 禁用 set_time_limit，则 php -d 方式仍有效，而脚本内调 set_time_limit() 会失败。
脚本内部主动延长：必须放最前面
如果你控制脚本源码（比如写了个 BuildScript.php），可以在入口处调 set_time_limit()：
<?php // 必须是脚本第一行可执行逻辑，不能在函数里、不能在 require 后面
set_time_limit(0);
// 后续才是你的耗时操作
exec('php artisan migrate --force');
- 放在
require或use之后？可能来不及生效 - 放在 try/catch 里？不影响超时判断
- 如果脚本被多次
include，每次都要重设
别漏掉 CI/CD 和系统级限制
即使 PHP 脚本不超时，整个流程仍可能被掐断：
- GitHub Actions 默认 job timeout 是 6 小时，但某些自建 runner 设了 20 分钟硬限制
- Docker 容器启动时用了
timeout 300 composer install，外层命令先杀进程 - GitLab CI 的
timeout配置优先级高于 Composer 任何设置 - PHP 的
memory_limit不足（如128M）会导致 OOM，被系统 kill，日志里常误判为“超时”
最易被忽略的是：脚本里调了 phpstan 或 phpcs 这类 dev-only 工具，但用了 --no-dev，结果命令根本不存在，卡在 shell 等待返回——这不是超时，是执行失败，但表现一模一样。
