三步基本能解决90%的composer update超时问题：调高超时阈值、禁用并行下载、换阿里云镜像源；根本原因是默认process-timeout仅300秒且并发下载易触发网络延迟超时。
直接调高超时阈值、禁用并行下载、换阿里云镜像源，三步基本能解决 90% 的 Composer update 超时问题。
为什么composer update总卡在Downloading或报Connection timed out
根本不是网络“不通”，而是 Composer 默认的 process-timeout 太低（仅 300 秒），加上默认启用并发下载，一遇到国内源响应慢、私有包解析卡顿或 DNS 解析延迟，就立刻触发 curl: (28) Operation timed out 或 file_get_contents(): failed to open stream: Connection timed out。
尤其要注意：update 会重新走完整依赖解析 + 包元数据拉取流程，比 install 更耗时、更易超时。
- 别指望只改一次配置就一劳永逸——
update过程中可能在多个阶段超时：元数据获取、包下载、VCS 克隆、post-update-cmd 执行 - 如果项目含
repositories字段（比如自定义 GitLab 源），它会优先于全局镜像配置，导致镜像失效 - 某些旧版
composer.lock里还存着已下线的镜像地址（如packagist.laravel-china.org），update会尝试访问它们并静默失败
如何用COMPOSER_PROCESS_TIMEOUT和--timeout真正生效
环境变量和命令行参数都有效，但优先级和适用场景不同。很多用户设了 process-timeout 却没生效，是因为没搞清它们作用的位置。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
COMPOSER_PROCESS_TIMEOUT=600 composer update：对整个命令生命周期生效，包括所有子进程（如git clone、php artisan） -
composer update --timeout=600：只控制 Composer 主进程的执行时间，不覆盖子命令超时 -
composer config -g process-timeout 600：写入全局配置，但部分 CI 环境（如 GitHub Actions）因容器无状态，重启后丢失，必须显式设置 - PHP 自身限制也要同步放宽：
php -d max_execution_time=0 -d memory_limit=-1 composer.phar update --timeout=600
换镜像源后仍超时？检查repositories和composer.lock是否拖后腿
阿里云镜像（https://mirrors.aliyun.com/composer/）只代理 Packagist 官方包，不代理 git@、https://github.com/ 或私有 GitLab 地址。如果你的 composer.json 里写了自定义 repositories，Composer 仍会直连那些地址，镜像完全不起作用。
- 运行
composer config -g repo.packagist确认全局镜像已设为阿里云地址 - 检查项目根目录
composer.json中是否有"repositories"字段，特别是包含"type": "vcs"或硬编码packagist.org的条目 - 执行
composer update --dry-run -v，看日志里实际请求的是哪个域名——如果出现https://packagist.org或已停用镜像地址，说明配置被覆盖 - 若
composer.lock里记录了失效源（如"url": "https://packagist.phpcomposer.com"），必须删掉vendor/和composer.lock，再用composer install重建
post-update-cmd卡住才是真瓶颈，别只盯着网络
很多 update 超时其实发生在脚本阶段，比如 Laravel 的 php artisan config:cache 或 Symfony 的 cache:warmup，尤其在 WSL2、Docker for Mac 或 NTFS 挂载卷上，I/O 延迟会让这些命令远超 5 分钟。
- 查看
composer.json的"scripts"段，临时注释掉"post-update-cmd"再试update - 手动运行疑似卡顿的命令，加
--no-interaction和-v看输出：php artisan config:cache --no-interaction -v - 若确认是缓存生成慢，可先
update完再单独运行脚本，避免耦合超时 - 注意：某些包的
post-update-cmd会递归扫描vendor/下大量 symlink，Linux 主机上建议用composer install --no-dev减少体积
最常被忽略的一点：超时未必是网络或配置问题，而是 composer update 在尝试解析一个根本不存在的版本约束（比如 "laravel/framework": "dev-main" 但主干已重命名），它会反复重试直到超时——这种情况下，--dry-run -v 日志里会出现大量 Could not parse version constraint 提示，而不是连接错误。
