设 process-timeout=0 会导致命令无限挂起，因Composer完全禁用超时熔断，遇网络假死、Git停滞或下载卡顿将不报错、不退出；http.timeout=0 同样危险，会使HTTP层放弃所有超时判断，导致Downloading卡住且无响应。
设 process-timeout=0 会导致命令无限挂起
Composer 不会主动终止任何子进程，process-timeout=0 表示完全禁用超时熔断机制。一旦遇到网络假死（如镜像不可达但 TCP 连接未断）、Git 服务器响应停滞、或 ZIP 包下载卡在中间字节，命令就会持续等待，不报错、不退出、不释放控制权。
http.timeout=0 同样危险，且更隐蔽
这个值会让 Composer 在 HTTP 层彻底放弃超时判断：DNS 解析失败、TLS 握手卡住、首字节迟迟不来、甚至整个 body 传输中断——只要底层 socket 没关闭，它就一直等。常见现象是 Downloading https://... 停住不动，-vvv 输出最后一行永远停在 cURL 请求上，无错误、无重试、无 fallback。
为什么不能只靠设 0 来“一劳永逸”
-
process-timeout=0不解决根本问题，只是掩盖资源瓶颈：内存不足（memory_limit小于 1.5G 时composer update极易卡在 SAT 求解）、磁盘 I/O 慢（如 WSL2 下 symlink 处理）、APCu 未启用（autoload 生成慢）都会表现为“没反应”，和 timeout 无关 - CI/CD 环境中，外层有
timeout命令或docker run --stop-timeout时，Composer 进程会被系统级 kill，此时你看到的不是ProcessTimedOutException，而是signal: killed或直接静默退出，根本来不及记录日志 - 私有 Git 仓库走 SSH 时，
process-timeout会累加每次git clone、git checkout的耗时；设为 0 后，一个仓库卡住，整条链路就全堵死
真正该做的不是设 0，而是分层控制
先用 composer install -vvv 确认卡点在哪一层，再针对性调整：
- 停在
Loading composer repositories→ 查 DNS / 换镜像，调http.timeout（推荐 600） - 停在
Executing command (CWD: ...)→ 调process-timeout（开发机 600，CI 推荐 1200～1800） - 停在
Generating autoload files→ 检查memory_limit、APCu CLI 开关、文件系统性能 - 所有超时配置都应配合兜底：GitHub Actions 用
timeout-minutes，Docker 用--stop-timeout，Shell 脚本外层套timeout 1800
最常被忽略的一点：设成 0 后如果真卡住了，你得手动 Ctrl+C 中断，而很多 CI 环境根本不允许交互 —— 那就只能等平台超时强制杀掉，连失败原因都抓不到。
