克隆中断后可抢救：进入含.git目录的半成品文件夹，执行git fetch --all --progress续传，再git checkout分支，含LFS仓库需额外git lfs fetch --all。
克隆大型仓库时网络超时中断，在 macos 上很常见，尤其涉及 hugging face、github 大模型库或含 git lfs 的项目。问题本质不是“克隆失败”，而是连接在传输中途被切断——git 无法自动续传，但其实可以抢救，关键在快速定位是哪一环断的。
先确认是否真为网络超时
看到类似以下报错，基本可锁定为网络层中断：
- fatal: unable to access 'https://...': SSL connection timeout
- error: RPC failed; curl 56: OpenSSL SSL_read: Connection was reset
- fatal: early EOF（数据流提前结束）
- fatal: index-pack failed（常伴随内存或连接异常）
注意：如果终端卡住十几秒后直接退出，且没输出具体错误，大概率是 TCP 握手或 SSL 协商阶段超时，而非下载中止。
检查代理和系统网络配置
macOS 上 80% 的 SSL timeout 类问题源于代理残留或冲突：
- 运行 git config --global --get http.proxy 和 git config --global --get https.proxy，若返回地址，说明 Git 正在走代理；此时关闭科学上网工具再试，或执行 git config --global --unset http.proxy 清除
- 检查系统设置 → 网络 → 高级 → 代理，确认「自动代理配置」或「网页代理（HTTP/HTTPS）」未意外启用
- 临时禁用所有网络扩展（如 Little Snitch、Surge、Clash 的 TUN 模式），它们可能劫持 Git 的 HTTPS 流量导致握手失败
绕过不稳定链路的实操方案
不依赖重试，直接换更鲁棒的传输方式：
- 改用 SSH 协议克隆：HTTPS 易受中间设备干扰，SSH 更稳定。确保已配置密钥：ssh -T git@github.com 或 ssh -T git@hf.co 能成功返回用户名
-
增大缓冲并禁用 IPv6（macOS 常见坑）：
git config --global http.postBuffer 524288000
git config --global http.version HTTP/1.1
git config --global url."https://".insteadOf "https://"（配合后续限速） -
强制走 IPv4 + 降低传输敏感度：
git -c http.version=HTTP/1.1 -c http.sslVerify=false clone --depth=1 https://...（仅调试用，勿长期禁用 sslVerify）
对已中断目录做恢复操作
只要 .git 文件夹存在，就不用从头来：
- 进入那个半成品目录：cd your-repo-name
- 继续拉取对象：git fetch --all --progress（加 --progress 可见实时进度）
- 检出分支：git checkout main（或 git branch -r 查看可用远程分支）
- 若提示“object not found”，运行 git lfs fetch --all（针对含 LFS 的仓库）
这一步能省下几 GB 到几十 GB 的重复下载，特别适合 Hugging Face 上动辄 20GB+ 的模型库。
