Composer install/update卡住主因是默认process-timeout仅300秒，控制git clone、unzip等本地子进程总耗时；应设为0禁用超时，而非混淆http-timeout（仅管HTTP下载）。
Composer install/update 时卡住，其实是默认 timeout 在作怪
Composer 默认的 process-timeout 是 300 秒（5 分钟），一旦某个命令（比如 git clone、unzip 或插件执行）超时，就会直接中断并报错 ProcessTimedOutException。这不是网络超时，而是子进程运行时间限制——所以调大或禁用它，才能让慢操作（如大包解压、私有 Git 仓库拉取）跑完。
设置 process-timeout 为 0 表示无限等待
Composer 官方明确支持将 process-timeout 设为 0 来禁用超时检查。注意不是设成负数或空值，只有 0 有效：
- 全局设置（影响所有项目）：
composer config -g process-timeout 0
- 当前项目设置（写入
composer.json的config段）：composer config process-timeout 0
- 单次命令临时生效：
composer install --process-timeout=0
或COMPOSER_PROCESS_TIMEOUT=0 composer update
改完后可通过 composer config process-timeout 验证是否生效。如果输出 0，说明已设置成功。
为什么不用 http-timeout？它和 process-timeout 不是一回事
别混淆这两个配置：http-timeout 控制的是 HTTP 请求（如访问 Packagist API、下载 zip 包）的连接/读取超时，默认 60 秒；而 process-timeout 控制的是本地执行命令（如 git、unzip、php 脚本）的总耗时。你遇到“卡在 Cloning into …”或“Extracting archive…”不动，基本都是后者触发的。
-
http-timeout影响下载阶段，设太小会导致file could not be downloaded -
process-timeout影响执行阶段，设太小会导致Command … timed out after 300 seconds - 两者可同时调整，但解决卡住问题，优先确认是
process-timeout
私有 Git 仓库 + 大包场景下，timeout 不是唯一瓶颈
即使设了 0，仍可能卡住：Git 协议本身有自身超时（如 SSH 连接超时）、磁盘 I/O 慢、PHP 内存不足（尤其解压几十 MB 的 zip）、或 Composer 插件（如 hirak/prestissimo）未适配无限等待。这时候要配合排查：
- 用
composer install -v看最后卡在哪条命令上 - 手动执行那条命令（比如复制出
git clone …），加-v观察真实阻塞点 - 检查
memory_limit是否过低（php -i | grep memory_limit），Composer 解压大包很吃内存 - 禁用插件测试：
composer install --no-plugins
真正需要无限等待的场景其实不多，多数时候是某环节异常缓慢被误判为“卡死”——先定位到具体命令，再决定要不要关 timeout。
