必须同步调高PHP的default_socket_timeout，否则Composer的http.timeout或process-timeout再高也会在60秒被底层socket强制中断；该值由php.ini控制，需通过php -i确认并手动修改，否则所有超时配置均无效。
Composer 的 http.timeout 或 process-timeout 再怎么调高，只要 PHP 底层的 default_socket_timeout 还卡在默认 60 秒，下载就一定会在 60 秒被掐断——这个值 Composer 完全不感知、也不覆盖，必须手动改。
为什么改了 Composer timeout 还是 60 秒就失败
Composer 所有 HTTP 请求（包括拉 packages.json、下载 ZIP 包）最终都走 PHP 的 fopen() / file_get_contents() 或 cURL 封装，而这些函数底层依赖 PHP 的 default_socket_timeout。它控制的是 socket 连接建立 + 数据读取的总等待时间，单位秒，CLI 模式下默认就是 60。
常见现象：
- 运行
composer install -vvv，日志停在Downloading https://...，几秒后直接报failed to open stream: Connection timed out -
composer config http.timeout 1200明明写了，但实际还是 60 秒断 - 用
curl -v https://mirrors.aliyun.com/composer/packages.json能通，但 Composer 就不行——说明是 PHP 层拦截，不是网络或代理问题
查当前 default_socket_timeout 值
运行这条命令确认你正在用的 PHP CLI 版本实际值：
立即学习“PHP免费学习笔记（深入）”；
php -i | grep default_socket_timeout
输出类似：default_socket_timeout => 60 => 60。注意：宝塔、Docker、WSL2 等环境常存在多个 PHP 版本，composer 默认调用的是系统 PATH 下的 php（通常是 /usr/bin/php），不是你网站面板里配的那个。
临时改（当前终端生效）
不用改配置文件，适合调试或 CI 一次性跑通：
- 加
-d参数覆盖：php -d default_socket_timeout=600 /usr/bin/composer install - 如果 composer 是 alias 或 shell wrapper，直接用完整路径调用更可靠
- 该方式只影响本次命令，退出终端即失效
永久改（需重启 PHP）
找到你 Composer 实际调用的 PHP CLI 的 php.ini 文件位置（不是 FPM 的）：
- 查路径：
php --ini→ 看 “Loaded Configuration File” 那行 - 常见位置：
/etc/php/8.2/cli/php.ini（Ubuntu）、/usr/local/etc/php/8.2/php.ini（Mac Homebrew）、/www/server/php/82/etc/php.ini（宝塔） - 编辑该文件，搜
default_socket_timeout，改成你需要的整数（如600） - 改完保存，**重启 PHP CLI 环境**：Linux/macOS 不需要“重启服务”，但宝塔用户必须点“重载配置”或重启对应 PHP 版本；Docker 则需重建容器
验证是否生效：php -r "echo ini_get('default_socket_timeout');" 输出应为新值。
最易忽略的一点：很多人改了 Composer 配置、换了镜像、配了代理，却始终没动 default_socket_timeout ——它就像一道隐形防火墙，挡在所有超时设置之前。不碰它，其他操作都是在给定时炸弹调表盘。
