鲸游先说一个我上周刚碰到的画面：团队里来了个实习生，想用 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 ob