process-timeout=0仅取消proc_open子进程超时，HTTP请求、解包、脚本执行等环节仍有独立超时控制；需同步配置http.timeout和环境变量才能真正延长整体超时。
直接设 process-timeout=0 不能真正取消超时，它只是把 PHP 的 proc_open 子进程等待上限设为“不限”，但 Composer 自身的 HTTP 请求、解包、脚本执行等环节仍有独立超时控制。
为什么 process-timeout=0 不等于“完全不超时”
Composer 的超时分三层：底层进程（proc_open）、HTTP 客户端（curl 或 ext-curl）、以及部分命令内置逻辑（比如 install 解压大包时的硬性等待）。设 process-timeout=0 只影响第一层——即执行 git clone、unzip 这类外部命令时的等待时间。HTTP 下载失败、SSL 握手卡住、或 packagist 响应慢，照样会报 Connection timed out 或 cURL error 28。
-
process-timeout默认是 300 秒，设为 0 表示“不主动 kill 子进程”，但系统级 timeout（如 Linuxkill -9信号）仍可能介入 - HTTP 超时由
http.timeout控制，默认 300 秒，也得单独设 - 某些插件或自定义脚本（如
post-install-cmd）用的是自己写的 exec 逻辑，不受 Composer 全局配置约束
正确设置长时操作的三步实操
要真让 Composer 在慢网、大包、CI 环境里跑完，得同步调三个地方：
- 全局配置
process-timeout：运行composer config -g process-timeout 0 - 全局配置
http.timeout：运行composer config -g http.timeout 0（注意：设 0 表示禁用 curl 超时，但部分旧版 cURL 不支持，建议设成3600更稳） - 临时绕过（推荐用于 CI）：在命令前加环境变量，比如
COMPOSER_PROCESS_TIMEOUT=0 COMPOSER_HTTP_TIMEOUT=3600 composer install
注意：http.timeout=0 在某些 PHP+cURL 组合下会退化为 300 秒，不是所有环境都真正生效；设成 3600（1 小时）反而更可靠。
常见错误现象和对应检查点
遇到“卡住”或“超时退出”，别急着改 process-timeout，先看日志里具体哪一步崩了：
- 报
fork failed: Cannot allocate memory→ 不是超时，是内存不足，process-timeout再大也没用 - 报
cURL error 28: Operation timed out after 300000 milliseconds→ 是 HTTP 超时，得调http.timeout，不是process-timeout - 报
Script xxx handling xxx event returned with error code 1→ 是脚本本身失败，跟 Composer 超时无关，得看脚本输出 - 本地 OK、CI 失败 → 很可能是 CI 容器没配
/dev/shm或 tmpfs，导致unzip解压大包时卡死，这时调 timeout 没用，得改环境
真正难搞的从来不是参数值设多大，而是得分辨清楚：到底是网络慢、磁盘慢、内存小，还是脚本写死了超时逻辑。超时配置只是最后一道闸门，不是万能油。
