Composer install/update 下载大包中断本质是 cURL 默认超时（总300秒、连接10秒）导致；应全局配置 timeout 600 和 connect-timeout 30，或临时用 --timeout=1200，失败时配合 --no-cache 重试，并排查镜像源、代理、ulimit 等底层问题。
composer install/update 时下载大包中断，本质是 HTTP 超时触发了 cURL 错误
默认情况下，composer 使用 cURL 发起 HTTP 请求，而其底层依赖的 curl_setopt 默认设置了 CURLOPT_TIMEOUT（总超时）为 300 秒、CURLOPT_CONNECTTIMEOUT（连接超时）为 10 秒。遇到镜像源响应慢、网络抖动或下载几十 MB 的扩展包（如 phpstan/phpstan 或某些带二进制的包）时，很容易卡在 Downloading http://.../package.zip 然后报错：cURL error 28: Operation timed out after 300000 milliseconds。
改全局配置：用 config 命令设置 timeout 和 connect-timeout
这是最直接、对所有后续命令生效的方式。注意两个参数含义不同，必须同时调大：
-
timeout控制整个请求生命周期（DNS + 连接 + 传输），单位是秒，建议设为600（10 分钟）起步 -
connect-timeout只控制建立 TCP 连接阶段，单位是秒，建议设为30（避免在弱网下反复重试连接） - 执行命令：
composer config -g timeout 600和composer config -g connect-timeout 30 - 配置会写入全局
~/.composer/config.json，不影响项目级配置
临时覆盖：用 --timeout 参数绕过当前命令的超时限制
适合一次性调试或 CI 场景，不改动任何配置文件：
-
composer install --timeout=1200（单位秒，支持整数） -
--timeout仅作用于当前命令的 HTTP 下载阶段，不影响脚本执行或 autoloader 生成 - 如果仍失败，错误信息里出现
Failed to decode response，说明不是超时而是压缩包损坏——此时需加--no-cache跳过本地缓存重试 - 该参数在 Composer 2.2+ 才完全稳定；旧版本（如 1.x）可能忽略或行为不一致
镜像源本身不稳定？别只调 timeout，顺手换源或关校验
超时只是表象。国内用户常因镜像同步延迟或 CDN 节点异常导致下载卡死，这时光调时间没用：
- 换更稳定的镜像：
composer config -g repo.packagist composer https://packagist.phpcomposer.com（已停用）或改用https://mirrors.aliyun.com/composer/ - 关闭哈希校验（仅限可信环境）：
composer config -g secure-http false，避免 HTTPS 中间证书问题引发连接 hang 住 - 禁用并行下载可降低并发压力：
composer config -g concurrent.http 1，尤其在低带宽或高丢包环境下有效
真正麻烦的是混合场景：公司内网走代理、镜像源启用了防盗链、PHP 进程被 ulimit 限制了 socket 数量……这些不会报 “timeout”，但表现一模一样。遇到反复失败，先 curl -v https://repo.packagist.org/packages.json 看底层是否通，比狂调 timeout 更省时间。
