Composer install/update卡住通常是process-timeout（默认300秒）触发进程中断，常见于内网拉包、大包解压、CI资源受限等场景；可通过命令行--process-timeout=600、composer.json配置或全局config设置，但不推荐设为0；需结合网络、解压工具、脚本优化及PHP配置排查根本原因。

composer install 或 update 卡住，实际是 process-timeout 在起作用

Composer 默认的 process-timeout 是 300 秒（5 分钟），一旦某个命令（比如 git clone、unzip 或脚本钩子）超过这个时间，就会被强行 kill，报错类似：Process timeout exceeded。这不是网络或权限问题，而是 Composer 主动中断了进程。

常见于：内网拉私有 Git 包、大体积扩展包解压、CI 环境资源受限、PHP 脚本钩子执行慢等场景。

• 修改方式优先级：命令行参数 > composer.json 配置 > 全局配置
• 命令行最直接，适合 CI/临时调试：composer install --process-timeout=600
• 若想长期生效，可在项目根目录的 composer.json 中加：

  "config": {
    "process-timeout": 600
  }

• 注意：该值设为 0 表示禁用超时，但不推荐——万一卡死就彻底 hang 住，尤其在自动化流程里更危险

全局设置 process-timeout 影响所有项目，慎用

运行 composer config -g process-timeout 600 会写入全局配置文件（通常是 ~/.composer/config.json），之后所有项目默认都用 600 秒。看似省事，实则埋雷：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• 不同项目依赖差异大：有的只是小工具包，根本不需要 10 分钟；有的跑测试脚本却仍可能超时
• 团队协作时容易“静默覆盖”——别人没意识到你改了全局配置，本地复现不了问题
• CI 环境通常应显式传参（如 --process-timeout=600），避免依赖机器上的全局状态

process-timeout 不解决根本性能问题，只是兜底

把 process-timeout 设成 600 并不能让慢操作变快，它只延迟失败时间。如果频繁触发超时，说明有更深层问题：

• Git 包拉取慢？检查是否用了 HTTPS 而非 SSH，或是否命中了低速镜像源
• 解压慢？确认 unzip 是否可用，或是否启用了 7z 替代（Composer 会自动 fallback，但某些容器里没装）
• 脚本钩子（如 post-install-cmd）超时？应单独优化脚本逻辑，而非一味调高 timeout
• PHP 内存不足也会表现为“假性超时”，可同时检查 memory_limit 和 composer diagnose 输出

PHP CLI 配置和 Composer 版本也会影响实际表现

process-timeout 的行为在不同 Composer 版本中略有差异，且严重依赖底层 PHP 进程控制能力：

• Composer 2.2+ 对 Windows 的 proc_open 超时处理更稳定；旧版本在 WSL 下可能误判
• PHP 编译时若禁用了 pcntl（如某些 Alpine 容器），process-timeout 会退化为无效——此时只能靠外部 timeout 工具（如 GNU timeout 命令）包裹
• CLI 模式下 max_execution_time 若设得太小（如 30），也可能提前中断 Composer 自身，需一并检查：php -r "echo ini_get('max_execution_time');"

有些项目卡在 post-autoload-dump 阶段，看着像超时，其实是 autoloader 生成逻辑有循环引用——这时候调高 process-timeout 只是掩盖症状。