Composer 脚本无内置超时配置，实际超时由 PHP 的 max_execution_time、CI/CD 环境限制或系统级超时决定；config 中的 process-timeout 仅影响 install/update 的子进程，与 scripts 无关。
Composer 默认对 scripts 中执行的命令没有硬性超时限制，但实际运行中会受 PHP 的 max_execution_time、系统级进程限制（如 shell 超时）、以及 Composer 自身的底层 HTTP 请求超时（仅影响 install/update 等网络操作）影响。脚本本身超时，**不是靠 composer.json 配置项控制的**，而是由执行环境决定。
PHP 的 max_execution_time 是主要瓶颈
Composer 脚本本质是通过 PHP 进程调用，比如 "post-install-cmd": "php artisan migrate"，最终由 PHP 解释器执行。若脚本里有长时间运行的 PHP 逻辑（如大数据导入、同步生成静态文件），就会触发 PHP 的执行时间限制。
- 默认值通常是
30秒（查看php -i | grep max_execution_time） - 可在脚本命令前显式覆盖：
"post-install-cmd": "php -d max_execution_time=300 artisan migrate" - 也可在
php.ini中全局调高，但不推荐用于生产环境
Shell 层面可能存在的隐式超时
某些 CI/CD 环境（如 GitLab CI、GitHub Actions）或容器平台会对单个命令设置默认超时（例如 10 分钟）。这时即使 PHP 允许跑 1 小时，也会被外部中断并报错类似 ERROR: Job failed: execution took longer than 1h0m0s。
- 检查 CI 配置中的
timeout或job_timeout字段 - 避免在
composer.json的scripts中写超长阻塞操作；应拆分为异步任务或后台进程 - 必要时改用
nohup或timeout命令包装，例如："post-deploy": "timeout 600 php artisan queue:work --once"
Composer 自身不提供 script_timeout 类配置项
翻遍 Composer 官方文档与源码（截至 v2.7），composer.json 的 scripts 区域**没有任何字段用于设置脚本执行时限**。所谓“脚本超时配置”是常见误解。
-
"config": { "process-timeout": 300 }只影响composer install等内部子进程（如git clone、svn export）的等待时间，和自定义脚本无关 -
"config": { "fxp-asset": { "timeout": 600 } }是旧版插件配置，已废弃且不作用于脚本 - 试图添加
"script-timeout"或类似字段会被 Composer 忽略
{
"scripts": {
"post-install-cmd": [
"@php -d max_execution_time=600 artisan optimize:clear",
"@php -d max_execution_time=600 artisan view:cache"
]
},
"config": {
"process-timeout": 600,
"fxp-asset": {
"enabled": false
}
}
}
真正卡住脚本的，往往是 PHP 执行限制、CI 环境策略、或脚本自身未做分块/进度反馈。别在 composer.json 里找不存在的 timeout 键——先确认是哪一层在杀进程，再针对性处理。
