composer脚本超时由process-timeout硬编码300秒限制导致，需通过config或环境变量调整；确认方式为检查错误是否含processtimedoutexception或-v输出卡在本地命令；推荐项目级设1800秒，避免≥7200被忽略。
Composer 脚本超时不是 PHP 执行时间问题，而是 process-timeout 硬限制在起作用；所谓“异步执行”在 Composer 原生机制中并不存在，强行模拟反而增加不可靠性。
怎么确认是 process-timeout 导致脚本中断
关键看错误里是否含 Symfony\Component\Process\Exception\ProcessTimedOutException，或文字明确出现 The process timed out。加 -v 参数重跑：composer run-script deploy -v，观察最后输出的 Running command (CWD): 是哪条命令卡住。
- 如果最后是
php artisan migrate、npm run build或php tests/run.php这类本地命令，基本锁定为process-timeout触发 - 如果卡在
Downloading https://或报curl error 28，那是http-timeout或底层default_socket_timeout问题，和脚本无关 - 如果停在
Resolving dependencies，根本没发请求，是 DNS 或网络连通性故障，调任何 timeout 都无效
process-timeout 必须通过 config 或环境变量设，其他方式全无效
它由 Symfony Process 控制，硬编码默认 300 秒，set_time_limit()、php.ini 的 max_execution_time、系统 timeout 命令完全不生效。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 项目级（推荐，可提交进 Git）：
composer config process-timeout 1800，写入当前composer.json的config段 - 环境变量（CI/CD 首选）：Linux/macOS 下
export COMPOSER_PROCESS_TIMEOUT=1800，Windows 设系统级变量COMPOSER_PROCESS_TIMEOUT - 临时覆盖（仅调试）：
COMPOSER_PROCESS_TIMEOUT=1800 composer run-script deploy或composer run-script deploy --process-timeout=1800 -
composer config --global process-timeout在 Composer ^2.2+ 已废弃，别用
设多少才合理？别踩 7200 秒硬编码陷阱
process-timeout 不是越大越好——Composer 内部有硬限制：设为 7200 及以上会直接忽略，回退到默认 300 秒。
- 设为
0表示禁用检查，但不建议：SSH 失败或死循环脚本会无限 hang 住 - 本地开发常用
3000（50 分钟），CI 中1800（30 分钟）已覆盖绝大多数迁移、构建场景 - 若脚本稳定耗时超 30 分钟，说明它本身该拆分或加进度反馈，而不是靠拉长 timeout 掩盖问题
所谓“异步执行”只是障眼法，真正要盯的是脚本本身
Composer 没有原生异步机制。有人用 & 后台运行、nohup 或消息队列包装脚本，但这类操作绕过了 Composer 的生命周期管理，失败不报错、状态不可知、日志难追踪。
- 真正容易被忽略的是：超时只是表象，背后常是某条
post-install-cmd效率低下，或vendor目录存在大量 symlink 导致 autoload 生成极慢 - 加
-v输出能定位卡点，比如php artisan optimize卡住，就该查 Laravel 版本兼容性或 APCu 是否启用 CLI 模式 - WSL2 用户尤其要注意 symlink 解析慢，可临时关掉
composer install --no-symlinks测试是否改善
