Git Clone 下载慢、中断、权限问题排查与实战指南-代码聚汇网

Git Clone 下载慢、中断、权限问题排查与实战指南

GitGit Clone下载慢

|难度：普通|阅读约 42 分钟

先说一个我上周刚碰到的画面：团队里来了个实习生，想用 git clone 拉一个新项目的仓库。十分钟后他发来一张截图，命令卡在 Receiving objects: 45% 不动了，再过两分钟直接 connection reset by peer。我们围过去一看，那仓库也就几百 MB 的体量，正常网络下两分钟就能拉完。这不是个别现象。

我这些年见过太多人在 git clone 上栽跟头：下载慢还能忍，最多等久一点；最气人的是拉到 99% 突然中断，报一堆看不懂的错；好不容易拉完，又冒出 Permission denied (publickey)、Authentication failed 这种权限拦截。这篇文章我就把 git clone 从原理到实战彻底讲透，重点拆解下载慢、中断、权限这三大类问题，最后再给一份可以直接抄作业的完整流程。适合刚接触 Git 的新手，也适合被这些问题折磨过的老手用来做速查。

1. 为什么Git Clone这件“小事”能拦住一群人

1.1 一个不算罕见的翻车现场

很多人的第一反应是：git clone 不就是一条命令吗，能有什么技术含量？

实际上，git clone 这条命令背后要完成的工作，比大多数人想象的复杂得多。你输入一行命令，Git 客户端需要先解析远程地址、建立网络连接、完成身份认证，然后协商版本信息，接着下载一整套对象数据，最后还要在本地完成工作区文件的落地。任何一个环节出问题，整个克隆就会失败或卡死。

尤其是公司内部网络、校园网、跨运营商网络这些场景，问题会被无限放大。我甚至见过有人为了 clone 一个仓库，折腾了一整天，最后发现根本不是命令的问题，而是网络出口对某些端口做了限制。

1.2 三个典型的坑：下载慢、中断、权限

围绕 git clone 的常见问题，归纳下来就三类：

下载慢：仓库本身大、网络链路质量差、DNS 解析到了不理想的节点、文件数量多、压缩计算耗时，都会导致速度上不去。
中断：连接超时、TCP 被重置、端到端链路不稳定、下载阶段 pack' 文件传输时间过长，都可能导致进度条卡住然后失败。
权限：SSH 公钥没配置、HTTPS 账号密码错误、Token 权限不足、本地目录没有写入权限、Windows 下文件被占用等，统统表现为权限类报错。

这三类问题经常交织在一起，比如权限错误导致服务器直接断开连接，你看到的现象就是“中断”；网络不稳定导致传输超时，你看到的又可能是“权限错误”的假象。所以排查的时候不能只看表面报错。

1.3 这篇文章能帮你解决什么

我写这篇文章的目标很简单：让你在遇到这三个问题的时候，不再是百度搜“git clone 下载慢”然后随便复制一个命令碰运气，而是能自己判断“问题出在哪个环节”，然后针对性地处理。读完以后，你至少能掌握：

git clone 的底层执行过程，知道它卡住时卡在哪个阶段；
下载慢的定位思路和对应的加速手段；
克隆中断后如何不从头再来，实现“类断点续传”；
SSH 和 HTTPS 两套权限体系的核心配置方法；
一份覆盖多场景的标准克隆命令模板和避坑清单。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 先搞懂Git Clone的底层逻辑，再谈排错

2.1 clone执行时到底做了什么

git clone <repository> 看起来是“复制一个仓库”，实际上它内部是按下面几步执行的：

在本地创建一个新目录；
在该目录下执行 git init，初始化一个空的本地仓库；
添加远程地址 origin；
从远程仓库抓取所有引用（refs）和对象数据，这一步对应你平时看到的 Receiving objects；
检查默认分支（通常是 main 或 master）；
执行 git checkout 将默认分支检出到工作区，对应你看到的 Checking out files。

很多人在第 4 步卡住，在 Receiving objects 和 Resolving deltas 之间感受人生百态。这两个阶段之所以耗时，一部分是网络传输，一部分是本地 CPU 在做对象压缩/解压和 delta（差异）计算。

理解这个流程之后，你就知道一个关键结论：git clone 不是“直接复制文件夹”，而是先通过 Git 协议把仓库的历史数据全部拿到本地，再在本地重建工作区。所以，一个“看起来只有 100MB”的项目，如果它有很深的提交历史，实际传输的数据量可能远不止 100MB。

2.2 传输协议怎么选：HTTPS、SSH、Git协议

git clone 支持的协议主要有下面几种，实际用的时候很多人没想过它们之间的差异：

协议	地址示例	认证方式	适用场景
HTTPS	`https://github.com/user/repo.git`	账号密码 / Token	默认最通用，新手友好，多数防火墙只开 443 端口
SSH	`git@github.com:user/repo.git`	SSH 密钥	老手常用，免密、稳定，但要求 22 端口能连通
Git 原生	`git://github.com/user/repo.git`	无（只读）	很少用，默认 9418 端口，很多网络环境会封
本地文件	`/path/to/repo.git`	无	内网共享或本机拷贝，磁盘操作最快

我的建议是：如果你没有特殊偏好，公开仓库优先 HTTPS；内网仓库根据公司规定选 HTTPS 或 SSH。如果 SSH 22 端口经常超时，优先考虑 HTTPS，因为 443 端口在绝大多数网络环境下都是放开的，这个特性在排查中断问题时非常关键。

2.3 为什么大仓库一定会慢：对象计数、压缩与打包

git clone 下载慢，除了网络带宽，还有一个很容易被忽略的原因：Git 的传输机制不是按文件拉取的，而是按对象（object）拉取的。

Git 会先把要传输的数据打包成 packfile，然后传输打包后的内容。仓库的每次提交都是一个对象，如果提交历史非常长，或者仓库里存了大量二进制资源（图片、视频、打包产物），对象数量会非常惊人。

在传输之前，Git 还需要“协商”和“枚举”对象，这就是你看到的 Counting objects 阶段。这一步是在服务器端完成的，客户端只能等。仓库越大、对象越多，这个阶段就越慢。

另外一个隐藏的性能杀手是 delta 压缩：Git 会尝试用“差异”而不是“完整文件”来存储相近版本。这个操作可以在服务端做，也可以在本地做。某些仓库你看到 Resolving deltas 卡很久，就是本地在尝试对下载下来的 pack 做解析和校验，CPU 弱的机器卡个几分钟很正常。

2.4 权限校验发生在什么时候

权限错误之所以让人困惑，是因为它发生的时机不同，报错也不一样。

如果走 HTTPS，权限校验发生在 HTTP 协议层。服务器返回 401 或 403，Git 会根据你是否输入了用户名密码、密码是否正确、账号是否有该仓库的访问权限来弹出提示或直接报错。

如果走 SSH，权限校验发生在连接建立阶段。你的客户端用私钥签名，服务器用你的公钥验证。验证不通过时，服务器可能直接拒绝连接，错误信息通常是 Permission denied (publickey)。

还有一种情况是仓库本身存在，但你操作的路径没有本地写权限。比如在 /usr/local 目录下 clone，普通用户根本没有写入权限，这属于操作系统层面的权限问题，跟 Git 服务器无关。

理解这个分层，能帮你快速判断：看到“权限”类报错，先想清楚是“远端认证失败”还是“本地写不进去”。

3. 下载慢：找准瓶颈，再选择对应的止血方案

3.1 慢不等于同一个原因，先做四步诊断

git clone 慢，很多人第一反应是“用加速工具”，但这个问题就像身体不舒服直接吃抗生素，不了解病因很容易无效。

我建议你先花两分钟做四步诊断：

确认仓库体积：执行 git ls-remote <远程地址> 只能看到引用，看不到大小。可以看仓库主页的代码统计，或者 clone 时观察 Receiving objects 的百分比和速度。一个 1GB 的仓库，跑不出 100MB/s，和网络体验是两回事。
测试到目标服务器的连通性：用 curl -I https://github.com 看一下响应时间，如果响应很慢，说明网络链路本身不理想。用 ping 看丢包率，丢包高会导致大量重传，速度必然上不去。
观察卡在哪个阶段：卡在 Counting objects 是服务端压力大，卡在 Receiving objects 是传输瓶颈，卡在 Resolving deltas 是本地 CPU 吃紧。
对比不同出口网络：换个手机热点试试，如果热点下速度明显变快，说明问题出在你当前网络的出口链路上，跟 Git 配置无关。

3.2 最直接的“减少体积”方案：浅克隆与单分支克隆

慢的问题，最有效的手段不是“加速”，而是少传数据。

如果你只需要最新的代码，不需要完整历史，千万不要用默认的完整克隆。用 --depth 参数限制历史深度：

bash复制# 只拉取最近 1 条提交
git clone --depth 1 https://example.com/user/repo.git

# 只拉取最近 5 条提交
git clone --depth 5 https://example.com/user/repo.git

这个操作对克隆速度的提升非常明显。一个完整历史有几千个提交的大仓库，用 --depth 1 可能下载量直接减少 90% 以上。

如果仓库存在多个分支，但你只想拿一个分支：

bash复制git clone --depth 1 --branch main --single-branch https://example.com/user/repo.git

--single-branch 意味着只下载指定分支的历史，默认分支以外的引用都不会下载。对于“只想看看代码”的需求，这几乎是最优解。

不过要留意：浅克隆之后的仓库是没有完整历史的，后续如果你想把历史加深，需要执行 git fetch --unshallow。这个过程会拉取全部历史，依然会慢。所以浅克隆适合“我要读代码、改个 bug、提个 PR”，不适合“我要完整备份仓库”。

3.3 国内平台中转：用Gitee/GitCode镜像导入再clone

如果仓库不在国内节点，链路质量很糟糕，浅克隆都拉不动，我常用的方法是通过国内代码托管平台做中转。

以 Gitee（码云）为例，流程是：

在 Gitee 上点击新建仓库；
选择“导入已有仓库”，填入原仓库的 HTTPS 地址；
平台会把远端仓库完整镜像到 Gitee 的服务器（这一步由平台完成，通常很快，因为平台之间链路好）；
然后你从 Gitee 的地址 clone：

bash复制git clone https://gitee.com/你的用户名/仓库名.git

这个过程通常比直接从国外服务器拉快得多。GitCode、其他国内托管平台也支持类似流程。这个方法有两个注意点：

导入完成后，原仓库后续更新了你需要再次同步，它不是自动跟随的；
涉及商业机密或敏感信息的仓库，务必确认你是否有权导入第三方平台，不要随便把私有仓库镜像到外部平台。

从工程实践上讲，这个方案解决的是“网络可达性”和“跨境链路质量”问题，而不是“Git 配置问题”。我在遇到大仓库、又不想等的时候，优先用这招，实测稳定。

3.4 Git配置项调优：postBuffer、lowSpeedLimit、compression

有时候网络没问题，速度也慢，可能是 Git 客户端的默认配置不够合适。

下面是几个我实测有效的配置项：

bash复制# 增大 HTTP 缓冲，减少大对象传输时的网络小包中断
git config --global http.postBuffer 524288000

# 设置最低速度限制：低于 1KB/s 持续 60 秒则放弃
git config --global http.lowSpeedLimit 1000
git config --global http.lowSpeedTime 60

# 关闭“压缩”方面的部分开销，适合本地磁盘快但 CPU 弱的场景
git config --global core.compression 0

http.postBuffer 是调整 HTTP 请求体缓冲区的，默认值可能在 1MB 到 5MB 之间。当你要 push 大文件或者 clone 大仓库时，缓冲太小会导致 HTTP 请求被频繁拆分，增加失败概率。把它调到 500MB 左右，碰到大请求会顺滑很多。

http.lowSpeedLimit 和 http.lowSpeedTime 是“超时保护”：如果传输速度长时间低于阈值，Git 会自动放弃。默认模式下有些场景会一直卡着，设了这两个参数，至少失败得干脆，不会干等一小时。

core.compression 建议谨慎使用。Git 在打包和接收时都会做压缩，把压缩等级调低可以节省 CPU 时间，但会增大传输体积。在高带宽、低 CPU 的场景下值得一试，否则不建议动。

3.5 DNS与网络出口：换公共DNS，切换运营商网络对比

还有一个容易被忽略的因素：DNS 解析到的服务器节点。

代码托管平台通常在全球部署了多个 CDN 节点，你的 DNS 解析到的 IP 决定了你连接哪个节点。如果运营商默认 DNS 给你解析到一个很远或很忙的节点，速度自然上不去。

你可以手动换成公共 DNS，比如阿里的 223.5.5.5、腾讯的 119.29.29.29，然后清理系统 DNS 缓存。不同地区的实际效果不一样，建议先换一个 DNS 再测一次 clone 速度。

另外一个快速验证方法是：用手机热点，或者切换不同运营商网络（家里宽带 vs 手机流量）再试一次。我之前遇到过同一台电脑，用电信宽带 clone 一个仓库只有几十 KB/s，切到移动热点直接跑到 5MB/s。这种问题怎么调 Git 配置都没用，换网络出口立竿见影。

3.6 一个实测案例：如何把一次clone从5分钟压到30秒

举一个最近的实际例子。我有个仓库大概 800MB，包含大量图片资源和很长的提交历史，从某个国外托管平台直接 clone，速度在 100KB/s 左右徘徊，等了 5 分钟才 30%。

我的处理过程：

先取消这次克隆，改用国内托管平台导入该仓库（3 分钟完成镜像）；
从国内平台执行 git clone --depth 1 --single-branch --branch main，实际下载量从 600MB+ 降到 200MB 左右；
全程速度稳定在 5MB/s 以上，最终不到 30 秒完成。

你可以看到，这不是“魔法”，也没改任何 Git 协议，只是做了两件事：减少数据量 + 改善链路质量。这个思路同样适用于 docker 拉镜像慢、模型文件下载慢等场景：先判断是不是数据源连通性的问题，再判断是不是数据量过大，最后才考虑改配置。

4. 中断：克隆到一半断网，怎么“续传”

4.1 中断的本质：TCP断流与Git的失败模式

git clone 在传输阶段使用的是长连接。一旦网络抖动导致 TCP 断流，就会出现各种中断报错。常见的有：

connection reset by peer
RPC failed; curl 56 OpenSSL SSL_read: Connection was reset, errno 10054
packet_write_wait: Connection to xxx port 22: Broken pipe
remote: aborting (shallow remote already contains SHA-1)

这些报错本质上都在说一件事：传输没有完成，连接被中断了。

更尴尬的是，Git 默认的做法是“失败就失败”，不会自动续传。你重新执行 git clone，它会从头开始下载。对一个大仓库来说，这简直让人崩溃。所以我们的策略是两个：提前预防 + 断点续拉。

4.2 提前预防：Git超时参数与SSH保活

先看预防。之前提到过 http.lowSpeedLimit 和 http.lowSpeedTime，它们能让 Git 在网络质量急转直下时尽快失败而不是一直挂着。

对于 SSH 协议，网络空闲超时导致断连是常见问题。你可以在 ~/.ssh/config 里加一段配置防止 SSH 连接因为“太久没数据”被中间设备杀掉：

bash复制Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

这样客户端每 60 秒发一个保活包，中间网络设备就不会因为空闲把你的连接清掉。

另外，如果网络环境对长时间连接不友好，优先走 HTTPS 而不是 SSH。很多企业网络对 22 端口的长连接做了限制，但对 443 端口的 HTTPS 限制少很多。这是个很实用的经验。

4.3 断点补救：git init + fetch + checkout 完整流程

如果克隆确实中断了，有没有办法“从断点继续”？Git 本身没有原生的 git clone --resume，但我们可以用 git init + git fetch 的组合实现同样的效果，而且非常可靠。

具体流程如下：

bash复制# 1. 创建目录并初始化空仓库
mkdir -p myrepo
cd myrepo
git init

# 2. 添加远程地址
git remote add origin <远程仓库地址>

# 3. 执行 fetch（相当于 clone 的下载阶段）
git fetch origin <默认分支名>

这里的 git fetch 是可以重复执行的。如果第一次执行到一半断网了，网络恢复后再执行一次同样的命令，Git 不会重新下载已经完成的部分，而是从断点继续，因为对象数据在本地仓库里已经被记录下来了。重复执行 git fetch 直到没有错误，就说明所有对象都拉下来了。

然后切换到目标分支：

bash复制# 4. 建立并切换本地分支
git checkout -b main origin/main
# 如果远端默认分支不叫 main，替换为你实际看到的分支名

git checkout -b 会基于远端分支在本地创建工作区，把文件落地到磁盘。这一步对应 clone 最后的 Checking out files。整个过程等价于一次完整克隆，但你可以中途反复执行 fetch，实现了“手动续传”。

这是一条非常关键的技巧。我靠这个办法救回过不少在机场、高铁上网络不稳定时失败的克隆。记住一点：git fetch 是幂等的，重复执行没有副作用，它只会补齐缺失的对象。

4.4 完整性校验：fsck、git status、重新fetch的表现

中断传输最怕的是“看起来拉完了，实际对象损坏”。补救流程结束后，建议做一次完整性检查：

bash复制git fsck --full

如果输出没有 error 和 missing，说明对象库是完整的。git fsck 会扫描仓库中的所有对象，检查是否存在缺失或损坏。

再看一眼状态：

bash复制git status

如果提示当前分支跟踪正常、工作区干净，说明恢复流程结束。如果不放心，可以再执行一次 git fetch origin --prune，远端有引用更新的话它会继续补齐，没有的话会快速结束。

4.5 浅克隆的后续深度补充

如果你为了快速下载用了 --depth 1，后续发现自己需要完整历史，可以执行：

bash复制git fetch --unshallow

这会从远端拉取全部历史，耗时取决于仓库体量。如果网络环境不好，用前面说的“fetch 多次”思路，也可以分段处理，因为它本质是跟 git fetch 一样的机制。

5. 权限问题：从Permission denied到Authentication failed

5.1 第一重门：HTTPS账号密码与Token

HTTPS 克隆时，Git 会提示你输入用户名和密码。这里有个大坑：大部分代码托管平台已经不支持直接用账号密码作为密码，而是要求使用个人访问令牌（Token）。

输入用户名时填你的平台账号，输入密码时填 Token。以 GitHub 为例，你应该在 Settings > Developer settings > Personal access tokens 里生成一个 Token，权限范围内勾选 repo。

如果你不想每次 clone 都输入用户名密码，可以配置凭据存储：

bash复制# 把凭据保存到磁盘明文文件
git config --global credential.helper store

# 使用系统凭据管理器（macOS 用 osxkeychain，Windows 用 manager）
git config --global credential.helper osxkeychain

Windows 上比较常见的写法是：

bash复制git config --global credential.helper manager-core

配置完成后，第一次输入账号密码（Token）后会保存，后续不用重复输入。用 store 的要注意，凭据会以明文存在 ~/.git-credentials 里，个人电脑还好，共享机器上不建议这么做。

5.2 第二重门：SSH公钥体系与Permission denied (publickey)

SSH 协议下最常见的报错是：

code复制git@github.com: Permission denied (publickey).

这几乎可以断定是本机没有配置公钥，或者公钥没有添加到平台账号下。标准的处理流程是：

bash复制# 1. 生成 SSH 密钥
ssh-keygen -t ed25519 -C "your_email@example.com"
# 一路回车即可，如果不想每次输密码就不设置 passphrase

# 2. 查看公钥内容
cat ~/.ssh/id_ed25519.pub

把公钥内容复制到代码托管平台的 SSH Keys 配置页。添加完成后验证：

bash复制ssh -T git@github.com

看到 Hi username! You've successfully authenticated 之类的提示，说明 SSH 通了，再执行 git clone git@github.com:user/repo.git 就不会有权限问题。

如果你有多台设备、多个平台，不要重复生成太多密钥。可以在 ~/.ssh/config 里用 Host 配置区分：

code复制Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_github

Host gitee.com
    HostName gitee.com
    User git
    IdentityFile ~/.ssh/id_ed25519_gitee

这样配置后，不同域名走不同的私钥，避免混乱。

5.3 第三重门：本地目录权限和Windows文件占用

权限问题不只在远端。你 clone 到本地目录时，如果目标目录没有写权限，一样会失败。

Linux/macOS 上的表现是 Permission denied 或 cannot create directory。检查目标目录的写权限，然后用 sudo 换一个合适的目录，或者修改目录权限：

bash复制sudo chown -R $USER:$(id -gn) /path/to/directory

Windows 上一个很经典的报错是：删除一个仓库目录时提示“你需要来自 Administrators 的权限才能删除”。这通常不是 Git 的问题，而是该目录的 ACL（访问控制列表）被设置成了“只读”或归系统保护，或者里面有文件被进程占用。可以先关闭所有占用该目录文件的程序（比如 VS Code、终端），再尝试删除；还不行就检查目录属性里的“只读”复选框。

另外，Windows 下用 U 盘或 exFAT/FAT32 文件系统存放仓库时也要小心：这两类文件系统不支持 Unix 权限位，Git 会看到所有文件都被标记为“可执行”。这不是权限错误，但是一种权限相关的怪象，会导致 git status 显示大片文件变动。解决办法是设置 core.filemode false：

bash复制git config core.filemode false

5.4 多代码托管平台多账号如何不打架

很多人同时用 GitHub、Gitee、GitLab，每个平台的 SSH 密钥可能不一样。如果不做区分，Git 会用默认的 id_rsa 尝试所有连接，于是出现“在 GitHub 上能通，在 Gitee 上 Permission denied”的怪象。

解决方案就是前面提到的 ~/.ssh/config 按 Host 指定不同的 IdentityFile。这样每个平台都能找到正确的密钥，互不干扰。

HTTPS 方式下多账号的问题主要是凭据冲突。不同平台的 URL 不同，git 的凭据管理器会按 URL 分别保存，通常不会串。但如果你使用 credential.helper store，所有平台的凭据会写进同一个文件，如果账号密码（Token）一样的话，偶尔会取错。建议多账号场景使用系统凭据管理器，比如 Windows 的 manager-core。

5.5 Gitee clone报错“git did not exit cleanly (代码 128)”的典型推理

这个报错在 Windows + Gitee 场景特别常见。它本身不是单一错误，而是 Git 把底层错误信息吞掉之后给客户端（比如 TortoiseGit）返回的通用错误。

遇到它，正确思路是打开命令行，手动执行同样的 clone 命令，看到真实的错误输出。我在实际项目里见过以下几种根因：

账号密码错误或 Token 失效 → 重新配置凭据；
仓库不存在 / 没有权限 → 检查 URL 和账号权限；
SSH 密钥不对 → 换成 HTTPS 地址验证；
本地目录已有同名文件夹 → 换一个目录再试；
Windows 防病毒软件拦截 Git 进程 → 临时关闭实时防护测试，如果确认是这个问题再添加白名单。

记住一条铁律：GUI 工具的报错信息经常不够精确，滚回命令行是排查的第一步。

6. 实战避坑组合拳：直接抄走的完整流程

6.1 克隆前检查清单

与其反复踩坑，不如在 git clone 之前花 30 秒确认几个小事：

明确仓库地址：HTTPS 还是 SSH？本地目录有没有同名文件？
明确需求：需要完整历史，还是只看最新代码？需要所有分支，还是只用一个分支？
确认认证方式：HTTPS 的话 Token 是否有效？SSH 的话公钥是否已注册？
确认网络环境：到目标仓库的链路是否稳定？之前有没有 clone 失败的经历？
确认本地磁盘：剩余空间是否足够？大仓库建议预留 1.5 到 2 倍仓库大小的空间。

6.2 面向不同场景的标准克隆命令模板

我把常用的 clone 场景整理成模板，可以直接复制：

bash复制# 场景 1：快速获取代码，不需要历史
git clone --depth 1 https://example.com/user/repo.git

# 场景 2：指定分支，且不要其他分支
git clone --depth 1 --branch main --single-branch https://example.com/user/repo.git

# 场景 3：完整克隆且带子模块
git clone --recurse-submodules https://example.com/user/repo.git

# 场景 4：发布版稳定仓库，避免下载 LFS 大文件（需要安装 git-lfs）
GIT_LFS_SKIP_SMUDGE=1 git clone https://example.com/user/repo.git

# 场景 5：断点续拉（分步执行）
mkdir -p repo && cd repo
git init
git remote add origin https://example.com/user/repo.git
git fetch origin main
git checkout -b main origin/main

6.3 高频错误与快速处置速查表

报错信息	最可能原因	快速处置
`Permission denied (publickey)`	SSH 公钥未配置	生成密钥并添加公钥到平台
`Authentication failed`	密码/Token 错误	用 Token 代替密码，检查权限范围
`fatal: repository not found`	仓库地址错误或没有访问权限	确认 URL，私有仓库确认账号权限
`RPC failed; curl 56`	网络中断	用 `git init + fetch` 分段续拉
`error: RPC failed; HTTP 413`	POST 数据过大	调大 `http.postBuffer`
`Unable to negotiate`	密钥算法不支持	检查 OpenSSH 版本，升级客户端
`git did not exit cleanly`	GUI 工具通用报错	用命令行执行看真实错误
`fatal: destination path already exists`	目录已有同名文件	换目录，或确认已有仓库是否可用

6.4 克隆完成后的几个收尾动作

克隆完不等于万事大吉，我一般还会做几个动作：

检查远程地址：git remote -v 确认 origin 是正确的。
查看分支状态：git branch -a 看本地和远程分支情况。
处理子模块和 LFS：如果仓库依赖子模块，git submodule init && git submodule update；如果使用 Git LFS，确认 git lfs install 已执行，否则大文件会下载成指针文件。
验证工作区：git status 看有没有意外变动。

如果你用浅克隆方式拉下来的仓库，后续要参与开发，也别忘记历史深度的问题。需要提交的时候，--depth 1 不会阻碍提交，但某些平台在合并时可能会要求完整历史，到时候用 git fetch --unshallow 补全即可。

最后分享一个我自己的小习惯：凡是超过 500MB 的仓库，我从不用一条 git clone 直接拉。一定是先把 git init + git fetch 跑起来，用 --depth 控制初始下载量，跑完再慢慢决定要不要补全历史。这种方式看着麻烦，但至少不会在 99% 的进度条上崩溃之后恨不得砸电脑。你可以先拿几个常用仓库试试这套流程，熟悉之后基本就告别“等待两小时，失败一分钟”的循环了。