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 日志定位到底卡在哪一步。
