设process-timeout为0不等于禁用超时，它仅跳过PHP子进程计时器，但cURL、TLS、磁盘I/O等仍会触发中断或僵死；强烈建议设合理上限（如1800秒）而非0。
不能真正“禁用”，只能设为 0，但强烈不建议这么做——它会让 composer global require 或 composer install 在网络卡死、磁盘满、TLS 握手僵住时无限挂起，Ctrl+C 都可能失效，CI 流水线直接卡死。
为什么设 process-timeout 为 0 不等于“禁用超时”
Composer 的 process-timeout 设为 0，只是跳过 PHP proc_open() 子进程的秒级计时器，但底层 cURL 连接、PHP socket、系统信号仍会干预。实际中常见现象是：
- cURL error 28（Operation timed out）仍会触发，因为
http-basic-timeout默认仅 60 秒，它和process-timeout完全无关 - TLS 握手被中间设备重置后，进程卡在
* Initializing SSL connection，既不报错也不退出 - 解压大 ZIP 包时磁盘 I/O 阻塞，
process-timeout=0下 unzip 进程持续占用 CPU 却无进展
composer config -g process-timeout 0 会生效吗？
会写入 ~/.composer/config.json，且对所有全局命令（如 composer global require）生效，但有前提：
- 必须确认没被
COMPOSER_PROCESS_TIMEOUT环境变量覆盖（它的优先级更高） - PHP CLI 的
default_socket_timeout必须 ≥ 你期望的 HTTP 等待时间；查法：php -i | grep default_socket_timeout，若显示60，那哪怕process-timeout=0，cURL 也会在 60 秒断连 - Composer 2.2+ 用户还必须同步设
http-basic-timeout，否则单次 ZIP 下载仍会在 60 秒失败
真正安全的“延长等待”替代方案
比起设 0，更可控的做法是按场景设合理上限：
- CI/CD 环境：运行
composer config -g process-timeout 1800（30 分钟） +composer config -g http-basic-timeout 300（5 分钟） - 本地调试大包（如 Laravel dist）：临时加参数
composer install --timeout=2400 --http-basic-timeout=600 - 确保镜像生效：执行
composer clear-cache后再试，否则旧缓存会绕过新 timeout 设置 - 禁用 packagist.org 回源：运行
composer config -g repo.packagist false，避免慢速回源拖垮整个流程
最常被忽略的一点：设了 process-timeout 0 后，如果某次 git clone 因 SSH key 权限问题卡住，它不会报错，也不会超时退出——你会以为网络好了，其实只是进程僵在认证环节。这种静默卡死比明确报错更难排查。
