优先使用镜像源（如github.com.cnpmjs.org）替换github.com进行clone，并添加--depth 1参数跳过历史下载，可显著提速；注意镜像仅适用于公开仓库且不可写，私有库或需完整历史时需另寻方案。
用 git clone 时卡在 “Receiving objects” 怎么办
本质是 GitHub 官方服务器响应慢或本地网络走海外直连不稳定。不是 Git 本身有问题，而是默认走 https://github.com/xxx 这条路太挤。国内用户尤其明显，常卡在 20%–70%，甚至超时失败。
- 优先换协议：把
https://改成git://或ssh://不解决问题，因为 GitHub 已停用匿名git://，而ssh需密钥且不加速下载 - 真正有效的路径只有两条：改 host 绕过 DNS 污染（临时、不稳定），或换镜像源（推荐、可持续）
- 镜像源不是“代理”，它同步 GitHub 公开仓库的
git对象，不涉及登录态和私有库，所以只对公开项目生效
国内可用的 GitHub 镜像源怎么配
目前稳定可用的是清华大学 TUNA 和中国科学技术大学 USTC 的镜像服务，它们提供 git:// 协议兼容的 HTTP 接口，可直接替换 URL 中的域名部分。
- 清华镜像格式：
https://mirrors.tuna.tsinghua.edu.cn/github-cdn/+ 原始路径（需手动拼接） - 更简单做法：用
git clone时直接替换域名 —— 把github.com换成github.com.cnpmjs.org（注意不是.cn） - 示例：
git clone https://github.com.cnpmjs.org/torvalds/linux.git，实测比原地址快 3–10 倍 - 这个域名由 cnpm 维护，非官方但长期可用；USTC 镜像已下线，TUNA 不直接提供类似域名，需走完整路径重写（麻烦，不推荐）
全局替换 GitHub 域名会出什么问题
不能无脑把所有 github.com 替换成镜像域名，否则 push、pull、fetch 会失败，因为镜像站只读，不接受写操作。
- 只应在
clone新仓库时手动替换，不要配置全局url.*.insteadOf - 如果误配了
git config --global url."https://github.com.cnpmjs.org/".insteadOf "https://github.com/"，会导致后续所有git pull报错remote: Repository not found. - 修复方式：运行
git config --global --unset url."https://github.com.cnpmjs.org/".insteadOf - 私有仓库、GitHub Enterprise、GitLab 等完全不适用镜像，强行替换只会 404
还有没有更快的替代方案
对超大仓库（如 Linux kernel、Android AOSP），即使镜像也慢，这时得换思路：跳过历史、只取最新版。
- 加
--depth 1参数，只拉 HEAD 提交，不下载整个历史 ——git clone --depth 1 https://github.com.cnpmjs.org/torvalds/linux.git - 配合
--single-branch可进一步减少数据量，尤其适合只用 main 分支的场景 - 注意：
--depth 1后仓库是 shallow clone，无法git log查全部提交，也不能git checkout其他 commit；后续要用完整历史，得运行git fetch --unshallow（可能又变慢） - 某些 CI 场景下，
git clone --filter=blob:none（稀疏检出）也能显著提速，但要求 Git ≥ 2.17 且服务端支持
镜像源 + --depth 1 是当前最稳妥的组合，但别忘了检查目标仓库是否开源、是否允许镜像同步 —— 少数组织会在 robots.txt 或仓库描述里声明禁止镜像。
