设process-timeout=0等效于取消子进程超时限制，但不推荐长期使用；它仅禁用Composer主动中断（如git clone、unzip），无法解决网络卡死或资源瓶颈问题。
设 process-timeout=0 就是取消时间限制
Composer 没有“禁用超时”的开关，但把 process-timeout 设为 0 效果等同于取消限制——它会让 Composer 不再主动终止子进程（如 git clone、unzip、脚本执行）。这不是推荐做法，但确实在调试或 CI 环境中被广泛使用。
-
composer config -g process-timeout 0：全局生效，写入~/.composer/config.json -
COMPOSER_PROCESS_TIMEOUT=0 composer install：临时生效，优先级最高 -
composer install --process-timeout=0：命令行参数，注意必须带等号，--process-timeout 0会静默忽略
设为 0 后，若遇到网络卡死、SSH 无响应或 Git 仓库不可达，命令可能无限挂起，需靠外层 timeout 命令或容器 --stop-timeout 强制中断。
http.timeout=0 并不真正禁用 HTTP 超时
http.timeout 控制 DNS 解析、TLS 握手、首字节等待和整个 body 传输的总时间。设为 0 在 Composer 2.x 中**实际会被当作 300 秒处理**（即回退到默认值），不是真正禁用。所以别指望 composer config -g http.timeout 0 能绕过所有下载卡顿。
- 弱网下更稳妥的做法是设一个大值，比如
600或1200 - 同时检查 PHP 的
default_socket_timeout：若它低于你设的http.timeout，PHP 层会先掐断连接——运行php -i | grep default_socket_timeout查看，必要时用php -d default_socket_timeout=1200覆盖 -
http-basic-timeout（Composer 2.2+）可单独调高，它只管 HTTP Basic Auth 请求阶段，和http.timeout不冲突
set_time_limit(0) 对 composer install 无效
你在 PHP 脚本里调 set_time_limit(0)，只能延长当前 PHP 进程的执行时间；而 composer install 是靠 proc_open() 启动一堆子进程干活的，比如下载 ZIP、解压、跑 post-install-cmd。这些子进程完全不受 set_time_limit 影响。
- 它只在自定义脚本钩子里有效：比如你在
post-autoload-dump里写了个耗时 PHP 类，那里面调set_time_limit(0)是管用的 - 但在
composer.json的 scripts 里直接写"php -r \"set_time_limit(0); ...\""没意义——PHP CLI 启动后立刻执行完就退出，根本没机会生效 - CLI 模式下若
max_execution_time被disable_functions禁用，set_time_limit()会直接报错
取消限制 ≠ 解决问题，真卡住时得查根源
把所有 timeout 都设成 0 或极大值，只是让失败来得更晚，而不是避免失败。很多“超时”表象背后是别的问题：
- 内存不足：update 解析锁文件阶段 OOM，表现就是卡住或秒退，和超时一模一样；确认
memory_limit≥1.5G - Git 仓库卡在 SSH：type=vcs 的包会绕过镜像直连 GitHub/GitLab，此时要配
git config --global core.sshCommand "timeout 300 ssh" - packagist.org 回源未关闭：即使切了阿里云镜像，
composer config -g repo.packagist false没执行，还是会 fallback 到官方源拖慢整体流程 - CI 容器里没装 ext-zip/ext-xml：根本跑不起来，不是超时，是直接报 extension missing —— 先
php -m | grep zip确认扩展存在
真正难排查的，往往是多个 timeout 参数叠加作用（process-timeout、http.timeout、http-basic-timeout、PHP 的 default_socket_timeout），且各自生效范围不同。调参前先 -vvv 看最后卡在哪条命令，比盲目加 0 更省时间。
