Composer进程超时本质是git clone等子进程卡住被强制中止，非网络下载慢；临时禁用需用--timeout=0或设环境变量COMPOSER_PROCESS_TIMEOUT=0，后者更可靠且全局生效。

Composer 安装或更新时出现 Process timed out，本质是某个子进程（比如 git clone、unzip 或脚本执行）卡住超过默认 300 秒，Composer 主动中止了它。不是网络慢导致的“下载超时”，而是本地命令执行太久被 kill —— 所以调大 timeout 或关掉超时检测，往往比换镜像更直接有效。

怎么临时禁用超时（最快速验证）

直接跳过所有进程级超时检查，适合调试或内网稳定环境：

• 运行命令时加 --timeout=0 参数，例如：composer install --timeout=0
• 或者设环境变量：COMPOSER_PROCESS_TIMEOUT=0 composer update
• 0 表示无限等待；注意这不改变 HTTP 下载超时（那是 http.timeout），只影响 proc_open 启动的命令

为什么 COMPOSER_PROCESS_TIMEOUT 比 --timeout 更可靠

--timeout 只作用于当前命令，而 COMPOSER_PROCESS_TIMEOUT 是全局生效的环境变量，覆盖所有子进程（包括插件、脚本、自定义 installer 调用的 git 或 svn）：

• 在 CI/CD 中推荐写进部署脚本开头：export COMPOSER_PROCESS_TIMEOUT=600
• Windows 用户用 set COMPOSER_PROCESS_TIMEOUT=600（cmd）或 $env:COMPOSER_PROCESS_TIMEOUT=600（PowerShell）
• 值设为 600（10 分钟）通常够用；设太高可能掩盖真实卡死问题（比如权限错误导致 git 一直等 SSH 密码）

哪些场景容易触发这个超时，但其实不该硬调高 timeout

盲目加大超时只是掩耳盗铃，下面这些情况该优先排查根本原因：

• git clone 卡住：检查是否用了 SSH 地址但没配好密钥，或公司防火墙拦截了 git:// 协议 → 改用 HTTPS 源或配 git config --global url."https://".insteadOf git://

• 

  解压大包失败：某些 Windows 环境下 7z 或 unzip 权限异常 → 用 composer config --global archive-format zip 强制走 PHP 原生解压
• post-install-cmd 脚本 hang 住：比如调用了未安装的全局命令（php-cs-fixer），或脚本里写了交互式输入 → 改成非交互模式，或加 --no-interaction

真正难处理的是混合场景：比如某私有包用 SVN + 自定义 installer，又在 post-update 中跑前端构建。这种时候 COMPOSER_PROCESS_TIMEOUT 得分段调——开发机设 600，CI 设 1200，但必须配上 composer -v 日志定位到底卡在哪一步。