克隆大型仓库卡住（7%每次就卡住了）

克隆到7%就卡住，核心是大文件传输时网络链路不稳定（SSH 连接因长时间低速率传输被远端/防火墙掐断），且单纯增大缓冲区效果有限，需要针对性优化「传输策略」和「连接保活」，以下是按优先级排序的解决方法：

第一步：先验证 SSH 保活配置是否真的生效（关键！）

你之前可能没正确配置/生效 SSH 保活规则，导致传输到7%时连接超时被重置：

打开 MINGW64 终端，执行以下命令检查 SSH 配置文件：

bash 复制代码

# 查看 SSH 配置文件内容（确认 bitbucket.org 规则存在）
cat ~/.ssh/config

若显示 No such file or directory：说明没创建成功，重新执行以下命令创建：

bash 复制代码

# 强制创建 SSH 配置文件（覆盖空文件）
echo -e "Host bitbucket.org\n  HostName bitbucket.org\n  User git\n  ServerAliveInterval 10\n  ServerAliveCountMax 20\n  TCPKeepAlive yes\n  ConnectTimeout 300" > ~/.ssh/config
# 设置配置文件权限（必须 600，否则 SSH 会忽略）
chmod 600 ~/.ssh/config

若已有内容：确认 ServerAliveInterval 是 10（而非60）------ 7%卡住时传输速率慢，60秒保活间隔太长，改成10秒更频繁发保活包，避免连接被掐断。

测试 SSH 连接是否用了新配置：
bash 复制代码
```
ssh -v git@bitbucket.org  # 加 -v 看详细日志
```
日志中能看到 debug1: Applying options for bitbucket.org 说明配置生效。

第二步：优化 Git 传输参数（针对7%卡住的低速传输）

默认的 Git 传输参数会一次性拉取大文件，容易在低速时超时，改成「单线程+小批次+低速率」：

bash 复制代码

# 1. 全局配置：强制单线程传输（避免多线程占带宽被限流）
git config --global core.bigFileThreshold 100k
git config --global pack.threads 1
git config --global fetch.parallel 0

# 2. 增大缓冲区到 1GB（比之前更大，适配大文件）
git config --global http.postBuffer 1073741824
git config --global ssh.postBuffer 1073741824

# 3. 关闭 Git 压缩（减少远端解压耗时，避免卡住）
git config --global core.compression -1

第三步：核心方案------分段拉取（避开7%卡住的大文件批量传输）

直接克隆会一次性拉取所有对象，7%卡住说明刚好遇到大文件包，改用「先拉极小深度→再逐步加深」的分段方式，把大传输拆成小批次：

bash 复制代码

# 1. 先创建空仓库，关联远端（避免从头克隆的一次性压力）
mkdir nextgen && cd nextgen
git init
git remote add origin ssh://git@bitbucket.org/suunto/nextgen.git

# 2. 先拉深度 1 的「最小快照」（只拉最新提交的元数据，无大文件）
git fetch --depth=1 origin master --timeout=600 --single-branch

# 3. 若步骤2成功，再逐步加深深度（每次拉一点，避免卡住）
git fetch --depth=10 origin master --timeout=600
git fetch --depth=50 origin master --timeout=600
git fetch --unshallow origin master  # 最后拉全量（可选，若只需要浅克隆则跳过）

# 4. 检出分支（完成克隆）
git checkout master

若步骤2仍卡在7%：把 --depth=1 改成 --depth=0（仅拉分支信息），再手动拉取文件：

bash 复制代码

git fetch origin master --depth=0 --timeout=600
git fetch origin master --depth=1 --timeout=600 --no-tags  # 不加标签，减少传输量

第四步：临时规避------改用「断点续传」式克隆（Windows 专属）

如果上述方法仍卡住，用 Git 的 partial-clone 特性（只拉取当前需要的文件，跳过大文件批量传输）：

bash 复制代码

# 启用部分克隆，只拉取工作区文件（跳过历史大对象）
git clone --filter=blob:none --depth=1 ssh://git@bitbucket.org/suunto/nextgen.git nextgen

若提示 --filter 不支持：升级 Git 版本（MINGW64 下执行 pacman -S git 升级）。

第五步：排除本地环境干扰（容易忽略）

关闭 Windows 防火墙/杀毒软件（比如 360、Windows Defender）：
- 这些软件会扫描 SSH 传输的文件，导致7%时速率骤降甚至卡住；
检查 MINGW64 终端的「缓冲区大小」：
- 右键终端标题栏 → 选项 → 缓冲区 → 把「行数」调到 10000 以上，避免日志刷屏导致卡顿；
切换磁盘分区：
- 若 D 盘是机械硬盘，临时克隆到 C 盘（固态硬盘），再移动回去（机械硬盘读写慢会卡住传输）。

第六步：终极兜底------改用 HTTPS + 断点续传工具

如果 SSH 始终卡在7%，换 HTTPS 协议，并使用 git-lfs 或第三方工具断点续传：

bash 复制代码

# 1. 用 HTTPS 克隆（避开 SSH 端口限流）
git clone --depth=1 https://bitbucket.org/suunto/nextgen.git --timeout=600

# 2. 若 HTTPS 也卡住，安装 git-lfs 处理大文件
git lfs install
git clone --depth=1 https://bitbucket.org/suunto/nextgen.git --progress  # --progress 显示详细进度

关键排查点

若所有方法都卡在7%：大概率是远端 Bitbucket 服务器对 suunto/nextgen 仓库做了带宽限制，或公司网络对该仓库的 IP 做了限流；
临时解决方案：让同事克隆成功后，把仓库文件夹压缩发给你，你本地执行 git remote set-url origin ssh://git@bitbucket.org/suunto/nextgen.git 重新关联远端，避免自己传输。

进度验证

每一步执行后，用 git fetch --progress 查看详细进度（会显示具体拉取的对象ID和大小），能精准定位是哪个大文件导致卡住，比如：

bash 复制代码

git fetch origin master --depth=1 --progress

若显示 Receiving objects: 7% (1267/16441), 6.93 MiB | 3.40 MiB/s 后不动，说明该批次的第1267个对象是大文件，可针对性跳过：

bash 复制代码

git fetch --exclude=refs/tags/* --exclude=refs/heads/* --depth=1 origin master  # 只拉master分支，排除标签/其他分支

兜底

如果上面所有方法查询了还是不行，就退出git bash，进入nextgen 目录，打开cmd窗口

bash 复制代码

git fetch --progress --depth=1 origin develop
git checkout develop