根本原因是Composer默认超时仅300秒，国内网络环境下易触发curl 28错误；应调高process-timeout至1200并配置github-protocols为["https"]，配合阿里云镜像与preferred-install: {"*": "dist"}优化下载路径。
composer install/update 一直卡在 downloading，报 timeout 错误
根本原因是 Composer 默认的网络请求超时太短（默认仅 300 秒），尤其在国内源不稳定、镜像同步延迟或包体积大时，很容易触发 curl error 28: Operation timed out after 300000 milliseconds。这不是你网络断了，是 Composer 主动“放弃”了。
实操上最直接的解法是调高两个超时参数：
-
COMPOSER_PROCESS_TIMEOUT：控制单个命令（如git clone）执行上限，默认 300 秒 → 可设为600或1200 -
COMPOSER_HOME下的config.json中配置"process-timeout"和"github-protocols"（后者可避免 git 协议卡住） - 临时生效：运行前加环境变量，比如
COMPOSER_PROCESS_TIMEOUT=1200 composer update
修改 composer.json 或全局 config 增加请求等待时间
改配置比每次敲环境变量更省事，但要注意作用范围——项目级改 composer.json，全局改 ~/.composer/config.json（Windows 是 %APPDATA%\Composer\config.json）。
关键字段只有两个：
-
"process-timeout"：单位秒，建议设1200（20 分钟），别设0（表示无限等待，可能真卡死） -
"http-basic"和"github-oauth"不影响超时，别往这上面试 - 如果用阿里云镜像但还是慢，顺手加上
"github-protocols": ["https"]，强制走 HTTPS 而非 git://，能绕过某些企业防火墙拦截
示例片段（写进 config.json）：
{
"config": {
"process-timeout": 1200,
"github-protocols": ["https"]
}
}
国内用户绕不开的镜像与协议组合问题
单纯加 timeout 不解决根本瓶颈——很多超时其实发生在从 GitHub 拉 zip 包阶段，而国内直连 GitHub 极不稳定。这时候 timeout 再长也没用，得换传输路径。
推荐组合动作：
- 用
composer config -g repo.packagist https://mirrors.aliyun.com/composer/切全局镜像 - 确认镜像站支持
dist包加速（阿里云、腾讯云都支持），否则 fallback 到 GitHub 还是会超时 - 禁用
git协议拉取：加"preferred-install": {"*": "dist"}，避免触发git clone（它有自己的 timeout，且不响应process-timeout） - 若仍失败，检查是否被 DNS 污染 —— 直接
ping packagist.org，如果解析到国外 IP，就手动改 hosts 或换 DNS
timeout 设太高反而让问题更难定位
把 process-timeout 设成 3600（1 小时）看似保险，实际会让失败更隐蔽：你不知道是真卡住，还是包损坏、权限错误、SSL 证书过期等其他问题被 timeout 掩盖了。
调试建议分两步走：
- 先用
-vvv参数跑一次：composer update -vvv，看具体停在哪一行、哪个 URL、什么错误码 - 再针对性处理：如果是 SSL 错误，加
"disable-tls": true（仅测试环境）；如果是 DNS，就换镜像或 hosts - 生产环境上线前，务必把 timeout 收回合理值（比如 600），避免部署脚本无意义空转
超时只是表象，背后往往是网络路径、协议选择、镜像完整性三者之一出了问题。盯着 timeout 调数字，不如先看 -vvv 输出里那一行真实的失败请求。
