Composer脚本超时由PHP的max_execution_time控制，非Composer配置项；可通过php -d max_execution_time=0 composer install临时调整，或在脚本中调用set_time_limit()，同时需检查CI/CD及系统级超时限制。
Composer 默认的脚本执行超时是 300 秒（5 分钟），一旦你的自定义脚本（比如 post-install-cmd 或 pre-deploy）运行时间超过这个值，就会被强制中止并报错：Script xxx handling the xxx event returned with error code 1 —— 实际上常伴随 PHP Fatal error: Maximum execution time of XXX seconds exceeded 或静默 kill，尤其在 CI/CD 环境或执行耗时构建任务时非常常见。
为什么 timeout 不是 Composer 配置项？
很多人搜 composer.json timeout 会误以为能在 "config" 下直接设 "timeout": 600，但这是无效的。Composer 的 config.timeout 是控制 HTTP 请求超时（如包下载），和脚本执行无关。脚本本身由 PHP 进程运行，超时由 PHP 自身机制控制。
修改 PHP 的 max_execution_time（最常用）
这是最直接、兼容性最好的方式，适用于所有 Composer 脚本（包括通过 composer run-script 触发的）：
- 在调用前临时设置：
php -d max_execution_time=0 composer install
（0表示不限制；也可设为600） - 若用
composer run-script，同样生效：php -d max_execution_time=600 composer run-script post-build
- CI/CD 中（如 GitHub Actions）建议显式指定，避免依赖系统默认值：
php -d max_execution_time=900 composer install --no-interaction
- 注意：该设置只影响当前 PHP 进程，不影响其他并发脚本；且需确保 PHP CLI 配置允许覆盖（
max_execution_time在php.ini中未被disable_functions限制）
在脚本内部用 set_time_limit() 主动延长
适合你完全控制脚本逻辑的情况（比如自定义 PHP 类或独立入口文件），但要注意作用域和时机：
- 必须在脚本开始后尽早调用，例如在
MyBuildScript::run()第一行：<?php class MyBuildScript { public static function run($event) { set_time_limit(1200); // 延长到 20 分钟 // ... 后续耗时操作 } } - 如果脚本已嵌套在 Composer 的事件钩子中（如
post-autoload-dump），且你无法修改其入口，此法无效 -
set_time_limit(0)可禁用限制，但需确认服务器策略允许（部分共享主机禁止） - 该函数对 CLI 模式有效，但对某些 SAPI（如嵌入式 PHP）可能无效果
绕过超时的替代思路：拆分或异步化脚本
当脚本本身不可控（比如调用第三方 CLI 工具或 Node 构建），或超时时间需要动态判断时，硬调高 max_execution_time 可能掩盖设计问题：
- 将长任务拆成多个 Composer 脚本，用
composer run-script step1 && composer run-script step2串行，每步单独设超时 - 改用后台进程（如
nohup npm run build > /dev/null 2>&1 &），但需自行处理失败通知和状态检查 - 在 CI 中改用专用 job 执行构建，而非塞进 Composer 脚本里——Composer 应聚焦于依赖管理，而非构建编排
真正容易被忽略的是：PHP 的 max_execution_time 和系统级 timeout（如 Docker 的 stop_timeout、GitHub Actions 的 timeout-minutes）是叠加生效的。即使你在 PHP 层设了 0，容器或 CI 平台仍可能在 10 分钟后杀掉整个进程。务必检查全链路的限制点。
