根本原因是 Composer 默认的 http.timeout（60秒）和 process-timeout（300秒）过短，下载大包或镜像响应波动时易超时；建议在项目 composer.json 的 config 段设置 "http": {"timeout": 300} 和 "process-timeout": 1800。
composer install/update 一直卡在 downloading，报 timeout 错误
根本原因不是网络差，而是 Composer 默认的 process-timeout 和 http.timeout 太保守（默认 300 秒和 60 秒），尤其遇到大包（如 laravel/framework 或含二进制扩展的包）或国内镜像响应波动时，很容易中断。
实操建议：
- 优先调高
http.timeout：它控制 HTTP 请求单次连接/读取上限，对下载慢、镜像首字节延迟高最有效 - 顺带调整
process-timeout：它管的是整个命令执行总时长（比如解压 + 安装脚本），大项目跑 post-install-cmd 时容易超 - 别只改全局配置——项目级
composer.json更可控，避免影响其他项目
怎么在当前项目里永久生效 timeout 设置
直接改 composer.json，加 config 段，不依赖环境变量或命令行参数，CI/CD 也稳定：
{
"config": {
"http-basic": {},
"http": {
"timeout": 300
},
"process-timeout": 1800,
"fxp-asset": {
"enabled": false
}
}
}
说明：
-
http.timeout值单位是秒，300 表示单次 HTTP 请求最长等 5 分钟（含 DNS、连接、TLS 握手、首字节、body 传输） -
process-timeout是整条composer install命令最大允许耗时，1800 = 30 分钟，够跑完大多数含脚本的安装流程 - 如果用了旧版 Composer（http 子对象不被识别，得降级写成顶层字段：
"http-proxy": "", "github-oauth": {}, "http-timeout": 300
临时提速但不想改配置？用命令行参数覆盖
适合调试、CI 单次运行或不确定是否要长期改配置的场景。注意参数名大小写和层级：
-
composer install --timeout=1800：只覆盖process-timeout（旧版叫--process-timeout） -
COMPOSER_HTTP_TIMEOUT=300 composer update：通过环境变量设http.timeout，比命令行参数优先级高 - 别用
-vvv一起跑——日志刷屏会拖慢输出，反而让终端假死感更强 - 如果还卡，大概率是镜像源问题，先试
composer config -g repo.packagist composer https://packagist.phpcomposer.com切回旧国内镜像（新版 packagist.org 已支持 CDN，但部分地区仍不稳定）
为什么改了 timeout 还是超时？几个隐蔽坑点
timeout 不是万能解药，以下情况再调高也没用：
- DNS 解析失败：Composer 会卡在
Resolving dependencies阶段，跟 HTTP timeout 无关；可手动dig packagist.org或换 DNS（如114.114.114.114） - PHP 的
max_execution_time被设为 30（常见于共享主机）：Composer 进程会被 PHP 强制 kill，此时看错误里有没有Fatal error: Maximum execution time of 30 seconds exceeded - 镜像返回 503 或 302 循环跳转：timeout 再长也下不来，要用
curl -v https://mirrors.aliyun.com/composer/packages.json实测镜像可用性 - 磁盘满或 inodes 耗尽：Composer 解压时需要临时空间，
df -h和df -i都得看
真正卡住的时候，别急着狂调 timeout，先 strace -e trace=network,io composer install -v 看停在哪类系统调用上——这才是定位根因最快的方式。
