设 process-timeout 为 0 会禁用子进程（如 git clone、unzip、post-install-cmd）超时控制，导致无限挂起而非报错；虽可配合 http-basic-timeout=0 彻底关闭两级超时，但仅适用于离线调试等极少数可控场景，CI/CD 中严禁使用。
设 process-timeout 为 0 会怎样
它会让 Composer 完全禁用子进程执行超时控制，比如 git clone、unzip、php post-install-cmd 这类外部命令不再被主动中断。但「不中断」不等于「能成功」——如果网络卡死、磁盘满、镜像返回空响应或 TLS 握手僵在中间状态，进程就会无限挂起，Ctrl+C 有时都无效。
process-timeout=0 和 http-basic-timeout=0 必须一起设吗
必须。Composer 的超时是两级的：HTTP 层（如下载 ZIP 包头）走 http-basic-timeout，整个命令生命周期（含解压、脚本、重试）走 process-timeout。只设其中一个为 0，另一层仍会掐断，错误日志里可能只显示 The process "" exceeded the timeout 或 cURL error 28，掩盖了真实瓶颈。
-
http-basic-timeout=0控制单次 HTTPS 请求（如拉packages.json或 ZIP 前几 KB），新版 Composer 2.2+ 才支持 -
process-timeout=0控制整个composer install流程，包括后续解压和脚本执行 - 两者都为 0 时，
curl -v https://mirrors.aliyun.com/composer/packages.json卡住 10 分钟，Composer 也不会退出
哪些场景真需要设为 0
极少数确定可控的离线或调试环境：
- 本地搭建的私有 Packagist 镜像跑在 127.0.0.1，且确认所有包 ZIP 已预缓存，只是想跳过所有超时校验做压力测试
- Docker 构建中已用
timeout 300s composer install外层兜底，内部 Composer 可放心关超时 - 调试某条特定
post-install-cmd脚本，需观察它在无干扰下跑满多久，而非让它被提前杀掉
CI/CD、生产部署、共享开发机上一律不推荐——一次挂起会阻塞整条流水线，排查成本远高于多等两分钟。
比设 0 更稳妥的替代方案
设一个足够大但仍有兜底的值，配合外部监控更可控：
- 国内镜像 + 大包场景：
composer config -g process-timeout 1800（30 分钟） +composer config -g http-basic-timeout 600（10 分钟） - PHP CLI 的
default_socket_timeout必须 ≥http-basic-timeout，否则底层 socket 会在 60 秒就断连（查法：php -i | grep default_socket_timeout） - CI 中用
timeout 2100 composer install外层包裹，既防 Composer 内部逻辑失效，也防系统级资源耗尽
真正难处理的从来不是「时间不够」，而是「卡在哪一层没反馈」——设 0 会让问题从「超时失败」退化成「无声挂起」，反而更难定位。
