Composer install/update 卡住通常是 process-timeout 限制所致，其默认值为300秒，仅控制子进程（如git、unzip、脚本）运行时长，与网络超时无关；可通过全局、项目级配置或命令行参数调整，建议结合 -v 定位具体卡点。
composer install/update 时卡住，其实是 process-timeout 在起作用
默认情况下，Composer 执行每个命令（比如 git clone、unzip、脚本执行）最长只等 300 秒（5 分钟），超时就直接报错退出。这不是网络请求超时，而是「单个进程运行时间」限制，和你本地机器性能、包体积、PHP 配置都有关。
常见错误现象：[RuntimeException] The process timed out. 或卡在 Installing dependencies from lock file 后无响应，但 CPU/磁盘没压力——大概率是某个 post-install-cmd 脚本或解压大包耗时过长触发了它。
- 全局设置：运行
composer config -g process-timeout 1800（单位秒，这里设为 30 分钟） - 项目级设置：进项目目录后运行
composer config process-timeout 1800，会写入composer.json的"config"段 - 临时覆盖：加
--process-timeout=1800参数，如composer install --process-timeout=1800
process-timeout 不影响 HTTP 请求超时
别被名字误导：process-timeout 和 github-api-token、http-basic、或 Composer 内部用的 cURL 超时完全无关。它只管「启动的子进程」是否跑太久，比如 git、svn、php 脚本、unzip 等。
如果你遇到的是 Could not fetch https://repo.packagist.org/packages.json 这类网络错误，该调的是 PHP 的 default_socket_timeout 或环境变量 COMPOSER_HOME 下的配置，而不是这个值。
- HTTP 层超时由 PHP 的
stream_context控制，Composer 默认用 300 秒，但无法通过process-timeout修改 -
process-timeout: 0表示禁用超时检查（不推荐，可能真卡死） - 设太高可能掩盖真实问题，比如某 post-install 脚本有死循环，不如先定位具体卡在哪一步
如何快速定位是哪个进程超时？
Composer 不会直接告诉你「第 3 个脚本跑了 301 秒」，但可以通过加 -v（verbose）参数观察最后执行的动作：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
composer install -v
输出里找类似这样的行：Running command (CWD): php ./vendor/bin/phpunit --version，再看它后面有没有卡住。也可以用 strace（Linux/macOS）或进程监视器辅助确认。
- 加
--no-scripts跳过所有脚本，测试是否还超时——如果正常，说明问题出在post-install-cmd或post-update-cmd - 某些老旧插件（如
hirak/prestissimo）在高并发下载时可能触发子进程调度异常，导致误判超时 - Windows 上
git的 SSH 认证弹窗会被当成“无响应进程”，也会触发 timeout，这时应改用 HTTPS + token 或配好 SSH agent
process-timeout 和 memory-limit 的关系容易被忽略
这两个配置常一起调整，但作用完全不同：process-timeout 是时间维度，memory-limit 是内存维度。一个超时，一个爆内存，报错信息也不同（The process timed out vs Allowed memory size exhausted）。
实际中，大项目 composer update 可能既吃内存又耗时，所以经常要同时加大：
-
composer config -g memory-limit -1（不限制内存，慎用） -
composer config -g process-timeout 3600（1 小时，适合 CI 或离线构建） - CI 环境建议显式设置，避免因机器负载波动导致随机失败
最麻烦的情况是：你调高了 process-timeout，但脚本本身有阻塞逻辑（比如等一个永远不返回的 API），结果只是让失败来得更晚、更难排查。所以优先确认卡点，再决定要不要调这个值。
