应修改process-timeout配置，因其控制git clone、unzip等子进程最大执行时间，默认300秒，错误含“the process "" exceeded the timeout”即为此项触发；需设为1200或更高，项目级用composer config process-timeout 1200，全局用composer config -g process-timeout 900。
Composer报"The process timed out"该改哪个配置
直接改 process-timeout，不是 http.timeout，也不是 PHP 的 max_execution_time。错误里带 The process "" exceeded the timeout 就是子进程（比如 git clone、unzip、php artisan）执行太久被 Composer 主动杀掉，和网络下载无关。
-
process-timeout控制单个外部命令最大运行秒数，默认 300（5 分钟），弱网或含大量私有 Git 包的项目很容易超 - 设为
0表示禁用超时，但 CI 中不推荐——一旦镜像不可达或网络卡死，命令会无限挂起 - 项目级最稳：运行
composer config process-timeout 1200，写入当前composer.json的config段，可提交、可复现 - 全局生效：用
composer config -g process-timeout 900，写入~/.composer/config.json
为什么加了--timeout=600还是失败
常见原因不是参数没生效，而是写法或环境覆盖导致它被忽略。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 必须带等号：
--timeout=600，写成--timeout 600（空格）会被静默忽略 - 该参数只覆盖
process-timeout，对下载阶段卡在Downloading https://无效——那是http.timeout管的 - CI 环境中，Docker 容器可能被
docker run --stop-timeout或外层timeout命令提前 kill，Composer 还没反应就结束了 - 某些旧版 Composer（--timeout，得用
--process-timeout=600或环境变量
post-install-cmd 脚本超时怎么单独处理
脚本本身由 PHP 进程执行，超时由 PHP 控制，和 Composer 的 process-timeout 无关。
- 不能在
composer.json里配timeout字段——那字段不存在，也无效 - 临时方案：用
php -d max_execution_time=0 composer install，让整个 Composer 进程里的所有脚本都不受 PHP 时间限制 - 更精准做法：在脚本内部（如自定义 PHP 类或
artisan命令里）调set_time_limit(0)，但得确保它在逻辑早期执行，否则可能被后续代码覆盖 - 检查脚本是否卡在交互上：加上
--no-interaction参数，避免php artisan key:generate等命令等待 stdin
比调 timeout 更容易被忽略的三个点
很多构建失败根本不是时间不够，而是资源或配置错位。
-
php -i | grep default_socket_timeout查出的值若低于你设的http.timeout，连接会在 Composer 层还没反应前就被 PHP 底层掐断——常见默认值是 60，必须同步调高 - 用了
"type": "vcs"或git@地址的私有包，镜像源（如阿里云）完全不代理，仍走原始地址；这时候加 timeout 没用，得确认 SSH/HTTPS 可达或换 HTTPS+token 方式 -
composer install卡在Generating autoload files阶段？不是超时，是 PHP 递归扫描 vendor 下 symlink 或嵌套过深目录导致 I/O 阻塞，需调高memory_limit或临时加--no-autoloader
