Composer超时本质是process-timeout默认300秒不足，临时用--timeout=600参数覆盖，永久改全局配置composer config -g process-timeout 600，但需配合国内镜像源使用才有效。
Composer 执行超时，本质是 process-timeout 默认值（300 秒）不够用，尤其在低带宽、高延迟或依赖较多的项目中。直接调大这个值就能解决，但得知道在哪设、设多少、以及为什么不能无脑拉到 0。
如何临时绕过超时（适合单次安装/更新）
加 --timeout 参数是最快的救急方式，它会覆盖全局和项目配置：
composer install --timeout=600
常见场景包括：CI 环境首次构建、本地网络不稳定、下载 phpunit 或大型扩展包时卡在 Downloading...。
-
--timeout=0表示禁用超时（慎用，可能无限挂起） - 该参数只对当前命令生效，不影响后续操作
- 如果仍失败，说明不是超时问题，而是网络中断或源不可达
永久修改全局 process-timeout 配置
运行以下命令把默认值写入全局配置文件（通常是 ~/.composer/config.json）：
Digital IP Agent
下载
将公开的创作者、博主、播客主持人、YouTuber 或 X/Twitter 账号人物转化为可部署的 OpenClaw 代理。当用户提供 YouTube 链接、X（推特）链接等时使用。
composer config -g process-timeout 600
这样所有项目都默认用 600 秒，无需每次加参数。但要注意：
- 值设太高（如 3600）会让错误更难定位——你分不清是真慢还是已卡死
- 某些共享主机或 Docker 容器里，PHP 的
max_execution_time可能比 Composer 超时更早触发，需同步检查 - 修改后可通过
composer config -g --list确认是否生效
为什么不能只靠改 timeout？还要换镜像源
单纯拉长超时只是“拖时间”，不解决根本瓶颈。国内用户最常遇到的是连接 packagist.org 慢或丢包，此时 process-timeout 再大也白搭。
- 优先执行：
composer config -g repo.packagist composer https://packagist.phpcomposer.com（旧镜像，已停用）或更推荐：composer config -g repo.packagist composer https://packagist.proxy.tencent.com - 腾讯、阿里、华为云等都有稳定镜像，地址可查官方文档或
composer config -g repo.packagist当前值 - 镜像源 + 合理 timeout（建议 300–600）组合使用，才是稳定方案
真正麻烦的是混合场景：比如私有 GitLab 包走 SSH、公共包走 HTTPS 镜像，这时 timeout 是按整个命令生命周期计的，某个私有库 fetch 失败却耗尽全部超时时间——这种就得拆开处理，单独为 VCS 仓库配 git.clone-depth 或 github-expose-token，而不是一股脑调高 process-timeout。
