必须同时设置process-timeout和http-basic-timeout，二者默认为300秒和60秒，独立生效、不可替代；仅调其一极易在弱网、大包或CI环境中触发超时失败。
直接改 process-timeout 和 http-basic-timeout，只调一个大概率还是失败。这两个值默认分别是 300 秒和 60 秒，弱网、大包、私有 Git 仓库或 CI 环境下极易击穿。
为什么 composer install 卡在 downloading 或报 The process "" exceeded the timeout
这是 process-timeout 触发的——它控制 git clone、unzip、php artisan 这类子进程单次运行上限，默认 300 秒。错误里带引号为空的 The process "" exceeded the timeout 就是它。
-
http-basic-timeout控制单次 HTTP 请求（比如下载 zip 包）的总耗时，包括 DNS、TLS、首字节、body 传输，默认仅 60 秒，常被忽略 - 两者完全独立：process-timeout 长了，但 http-basic-timeout 还是 60 秒，照样卡在
Downloading https://... -
set_time_limit(0)、max_execution_time、--timeout=600（无等号）全无效——旧版参数名已废弃，新版必须用--timeout=或--http-basic-timeout=
怎么设才真正生效（命令行 / 项目级 / 全局）
优先级从高到低：命令行参数 > 项目 composer.json > 全局 config。注意写法，错一个字符就静默失效。
- 临时救急（CI 脚本里最常用）：
composer install --timeout=1800 --http-basic-timeout=300（必须带等号，空格会忽略） - 项目固化（推荐，可提交、可复现）：
composer config process-timeout 1800+composer config http-basic-timeout 300，会写入composer.json的config段 - 全局统一（适合 Docker 基础镜像预装）：
composer config -g process-timeout 1800+composer config -g http-basic-timeout 300，写入~/.composer/config.json - 值设为
0表示禁用超时，CI 中不推荐——网络卡死或镜像不可达时会无限挂起
为什么加了 timeout 还是失败？常见干扰项
超时只是表象，背后常混着其他问题，光调数字解决不了。
- 镜像未切对或回源开启：国内用户若没切腾讯云/阿里云镜像，或配置了
"packagist.org": {"type": "composer", "url": "https://packagist.org"}回源，大包仍走海外直连，http-basic-timeout再大也连不上 - 代理或防火墙限制：某些企业代理会截断长连接、丢弃大响应体，或限制 header 大小，导致分块下载失败；加
-v看日志，如果反复重试同一 URL 且状态码异常（如 503、403），就是这个原因 - Docker 容器被外层 kill：CI 中用
docker run --stop-timeout或 shelltimeout命令包裹 Composer，它根本没机会触发自己的超时逻辑就退出了 - post-install-cmd 脚本卡住：这类脚本由 PHP 进程执行，受
max_execution_time控制，和 Composer 的process-timeout无关；需单独处理，例如加--no-interaction避免等待 stdin，或在脚本内早期调set_time_limit(0)
真正稳的方案不是把 timeout 设到 3600，而是先确认是否真需要那么久——换镜像、关回源、验证代理策略，往往比硬扛超时更可靠。超时配置只是兜底，不是替代网络优化的捷径。
