Composer安装超时有什么终极解法？超时参数与国内镜像【精讲】-composer-PHP中文网

必须同步生效的三件事是换镜像源、清空缓存、调整http.timeout和process-timeout；仅做其一两步90%超时仍复现，且config命令易因拼写、格式、用户权限等错误静默失效。

composer安装超时有什么终极解法？超时参数与国内镜像【精讲】

没有“终极解法”，只有“必须同步生效的三件事”：换对镜像源、清空缓存、调对两个超时参数——缺一不可，只做其中一两步，90% 的超时仍会复现。

为什么 `composer config -g repo.packagist` 总是不生效

这个命令写错任意一处，就会静默失败：不报错、不提示、composer install 依然卡在 Loading composer repositories。常见错误包括：

repo.packagist 写成 repos.packagist（多一个 s），配置直接被忽略
漏掉末尾的 composer 类型标识，命令变成 composer config -g repo.packagist https://mirrors.aliyun.com/composer/，Composer 2.x 会 fallback 回 packagist.org
URL 末尾带斜杠 /，实际应为 https://mirrors.aliyun.com/composer（注意无尾部斜杠），否则请求路径拼成 /composerpackages.json 导致 404
执行用户与运行 Composer 的用户不一致，比如宝塔后台以 www 用户运行，但配置写进了 root 的 ~/.composer/config.json

验证是否真正生效：运行 composer config -g repo.packagist，输出必须是类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer"} 的完整结构，不能是 null、空值或 packagist.org。

`http.timeout` 和 `process-timeout` 到底管什么

这两个参数作用层完全不同，且在 Composer 2.2+ 中互不替代：

http.timeout 控制单次 HTTP 请求：从 DNS 解析、TCP 连接、TLS 握手到响应头返回的总耗时，默认仅 60 秒。它触发时错误通常是 Could not fetch https://... 或 cURL error 28
process-timeout 控制整条命令生命周期：含依赖解析、下载、解压、post-install-cmd 脚本执行等，默认 300 秒。它触发时错误是 The process timed out 或进程被 kill -9，日志里可能连具体 URL 都不显示
只改 --timeout=3600 参数无效：该参数仅覆盖 process-timeout，对 http.timeout 完全无影响
设超过 7200 秒会被 Composer 主动截断回默认 300 秒，这是硬编码限制，不是配置失效

推荐全局设置：composer config --global http.timeout 600 和 composer config --global process-timeout 1200，兼顾稳定性与可排查性。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

为什么换了镜像、调了超时，还是卡在 `Resolving dependencies`

镜像源只加速包下载（Downloading 阶段），不解决依赖解析慢的问题。如果 composer update 卡在 Resolving dependencies 几十秒以上，和网络无关，而是 Composer 在本地穷举版本组合：

"php": "^7.4 || ^8.0" 这类宽泛约束会让解析器尝试大量 PHP 版本 + 包版本交叉匹配
require-dev 中存在大量工具链（如 phpunit/phpunit、laravel/pint）会指数级拖慢解析速度
项目 composer.json 中启用了 "prefer-source": true，镜像源完全不代理 Git clone，Composer 会 fallback 直连 GitHub，触发 API 限流或 TLS 握手阻塞
CI 环境未固化 COMPOSER_HOME，每次构建都重读默认配置，导致镜像和超时设置丢失

生产环境应避免 composer update，始终基于已提交的 composer.lock 执行 composer install --prefer-dist --no-interaction。

CI/CD 中最容易被忽略的硬性操作

干净容器 + 无缓存 + 弱 DNS 策略 + 内存受限，让 CI 成为超时高发区。靠本地经验硬套必翻车：

必须显式启用缓存：GitHub Actions 写 cache: $HOME/.composer/cache，GitLab CI 配对应路径，否则每次重下百 MB zip 包
强制走 dist 包：composer install --prefer-dist --no-interaction --no-progress --timeout=7200，跳过 git clone 触发的 GitHub API 限流
企业网必须设 HTTPS_PROXY（不是 HTTP_PROXY），并确保证书可信；否则 Composer 默认全走 HTTPS，代理不生效
禁用默认源兜底行为：在全局配置中加 "packagist.org": false，防止因私有源配置错误而逐个 fallback 超时重试

最隐蔽的坑是：你以为配置写进去了，其实 composer config -g 写的是 root 用户，而 CI runner 用的是 runner 用户，家目录不同，配置根本没加载。