git clone卡住与composer配置无关，因超时由git自身控制；需调http.lowspeedlimit/time禁用低速检测、增大postbuffer、ssh则配core.sshcommand参数，并排查dns、认证、文件系统等根本原因。

Composer 本身不控制 git clone 超时，所有克隆阶段的超时都由系统 Git 决定 —— 改 Composer 的 http.timeout 或 process-timeout 完全无效。

为什么 git clone 会卡住，而 Composer 配置没用

Composer 在遇到 "type": "vcs" 或 "type": "git" 的包时，会调用系统 git clone 命令拉取代码。此时网络连接、认证、握手、传输全部交由 Git 处理，Composer 只是等结果。常见错误如：

• Cloning into 'xxx' fatal: unable to access 'https://xxx': Failed to connect to xxx port 443 after 75000 ms
• ssh: connect to host xxx port 22: Connection timed out

这类输出里带 Cloning into 或 fatal: 的，基本就是 Git 层失败，不是 Composer 配置能干预的。

怎么调 Git 的 HTTPS 克隆超时

HTTPS 协议下，Git 使用 libcurl，其超时行为由 http.lowSpeedLimit 和 http.lowSpeedTime 控制 —— 它们不是“总耗时”，而是“持续低于某速度多久就断开”。默认值会让弱网或大包直接中断。

Gitlab Mr Review Pipeline

自动化 GitLab MR 代码审查流水线，利用 AI 生成审查报告并邮件发送给提交人。

下载

• 禁用低速检测（最常用）：git config --global http.lowSpeedLimit 0 和 git config --global http.lowSpeedTime 0
• 增大缓冲区防中断：git config --global http.postBuffer 524288000（500MB）
• 若走代理，确认 http.proxy 设置正确，否则 Git 会卡在 DNS 解析上

怎么调 Git 的 SSH 克隆超时

SSH 协议不走 HTTP 栈，http.* 配置完全无效。必须通过 core.sshCommand 注入 OpenSSH 参数：

• git config --global core.sshCommand "ssh -o ConnectTimeout=30 -o ServerAliveInterval=30 -o ServerAliveCountMax=3"
• 确保 ssh -T git@your-git-server 能通；若公司网络拦截 SSH，别硬扛，改用 HTTPS + token
• 不要在 composer.json 里写 git@xxx，却只在 CI 里配了 HTTPS token —— 认证失败常被误判为“超时”

哪些操作根本治标不治本

盲目加 --timeout=0 或把 process-timeout 设成 3600，只会让问题更难定位。真正卡住的点往往是：

• 私有 GitLab 启用了双因素（2FA），但 token 权限不足 → 报 403，不是 timeout
• DNS 解析慢（尤其内网 Git 地址），git clone 卡在 Resolving host 阶段 → 要换 DNS 或 hosts 绑定
• WSL2 或 Docker 中挂载了 vendor/ 目录 → 文件系统转发导致 git checkout I/O 延迟飙升

Git 克隆超时的本质，是网络链路、认证方式、系统配置三者耦合的结果。单独调一个参数，不如先跑 git clone -v https://your-private-repo.git 看它到底停在哪一行。