私有 Git 仓库超时应调 process-timeout 而非 http.timeout，因其走 git clone 进程而非 HTTP 请求；需配合认证配置、CI 系统超时设置及资源限制综合排查。
私有 Git 仓库超时该调 process-timeout，不是 http.timeout
私有仓库（如 GitLab、GitHub 私仓、自建 Gitee）走的是 git clone 或 svn export 流程，Composer 把它当作「外部进程」而非 HTTP 请求处理。所以卡在 Cloning into 'xxx'... 或报 The process "git clone ..." exceeded the timeout，和 http.timeout 完全无关，必须调 process-timeout。
常见错误现象：
- 运行
composer install卡住十几分钟，最后抛出[RuntimeException] The process "git clone --no-checkout ..." exceeded the timeout - CI 日志里看到
Cloning into '/tmp/xxx'后长时间无输出 - 即使配了阿里镜像源、代理、
http.timeout=1200，依然超时
实操建议：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
process-timeout建议设为1200（20 分钟）起步：私有 Git 仓库常因 SSH 连接慢、大包体积（含 vendor 或 dist）、或 CI 环境磁盘 I/O 慢导致克隆耗时远超默认300 - 项目级配置最稳妥：
"config": {"process-timeout": 1200}写进composer.json，可提交、可复现 - 若用 SSH 克隆，确认
~/.ssh/config里已设ServerAliveInterval 30，避免中间网络断连被静默中断 - 不推荐设
0：一旦 Git 服务假死或 SSH 密钥失效，命令会无限挂起，CI 流水线彻底阻塞
私有仓库认证失败导致的“伪超时”要先排除
很多所谓“超时”，其实是认证失败后反复重试造成的假象。比如 Composer 尝试用 HTTPS 凭据拉取 git@gitlab.example.com:group/pkg.git，失败后退回到交互式密码输入，但 CI 环境无 TTY，就卡住不动，看起来像超时。
典型表现：
- 日志停在
Loading composer repositories with package information或Updating dependencies，无任何错误提示 - 加
-vvv后看到反复出现Failed to clone https://gitlab.example.com/group/pkg.git via https, ssh driver - 手动执行
git clone git@gitlab.example.com:group/pkg.git能通，但 Composer 不行
实操建议：
- 私有仓库必须通过
auth.json管理凭证，禁止硬编码到composer.json的repositories里 - 确保
auth.json路径正确：~/.composer/auth.json（全局）或项目根目录下auth.json（需composer config --auth生效） - HTTPS 私仓填
gitlab.example.com对应的 token；SSH 私仓则确保~/.ssh/id_rsa已加载且ssh -T git@gitlab.example.com能通 - CI 中优先用 deploy token 或 CI_JOB_TOKEN（GitLab），并挂载到容器内对应路径
私有 VCS 仓库不能加进镜像配置
国内用户习惯性执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，这没问题——但千万别把私有 Git 仓库也写成镜像形式，例如：
"repositories": [
{
"type": "composer",
"url": "https://gitlab.example.com/api/v4/groups/group/-/composer"
}
]
这是错的。Composer 的镜像机制只代理 Packagist 类型的 Composer 仓库（即提供 packages.json 的 HTTP 服务），不代理 Git/SVN 等 VCS 源。强行加进去会导致：
Failed to clone https://gitlab.example.com/group/pkg.git, could not connect to server- Composer 误以为这是个 Composer repo，去请求
packages.json，结果 404 后放弃，再试 HTTPS 克隆，再失败
正确做法：
- 私有仓库类型必须是
vcs，不是composer：
"repositories": [
{
"type": "vcs",
"url": "https://gitlab.example.com/group/pkg.git"
}
]
- 如果想统一管理多个私有包，用
composer repository自建一个 Composer repo（如 Satis 或 Private Packagist），再把它作为type: composer加入，这才是镜像适用场景 - 确认
composer.lock里对应包的source字段是"type": "git"或"type": "svn"，而不是"type": "package"（后者说明被错误扁平化了）
CI 环境下私有仓库超时要叠加系统级兜底
仅调高 process-timeout 不够。CI 容器本身可能有更严格的限制，比如 GitHub Actions 的 timeout-minutes、GitLab CI 的 interruptible: false + timeout，或者 Docker 的 --stop-timeout。这些会在 Composer 还没来得及报错前就把进程 kill 掉，日志里只剩 Killed 或空行。
排查要点：
- 检查 CI 配置是否显式设置了运行时限，且该值 ≤ Composer 的
process-timeout；必须让 CI 层 timeout > Composer 层 timeout - Docker 构建中，
docker build --timeout和COMPOSER_PROCESS_TIMEOUT要协同，前者至少比后者多留 2 分钟缓冲 - 某些 CI runner（如 self-hosted GitLab Runner）默认启用
ulimit -t（CPU 时间限制），会直接终止长时间运行的git进程，需在 runner 配置中禁用 - 内存不足也会表现为超时：私有包若含大量嵌套子模块或大体积 dist，
git clone --recursive可能 OOM；建议 CI 中设php -d memory_limit=2G并监控容器 RSS
真正复杂的地方在于：私有仓库的超时不是单一参数问题，而是认证链、网络链、进程链、系统链四层叠加。漏掉任意一层，都可能让 process-timeout=1800 形同虚设。
