1. 为什么 Git Clone 速度缓慢？
每次执行 git clone 或 git clone --recursive，看着进度条半天不动，是不是感觉自己的耐心正在被一点点消磨？尤其是当你需要拉取一个大型仓库，或者一个包含了十几个子模块的项目时，那种等待的滋味，简直就像在机场等一艘船。你可能试过网上流传的各种'偏方'：修改系统的 hosts 文件，把 GitHub 的 IP 指向某个据说很快的地址；或者干脆把远程仓库的地址换成国内的镜像源。这些方法有时候确实能起点作用，但很多时候效果并不稳定，今天快，明天可能又慢了，而且每次都要手动操作，非常麻烦。
更让人头疼的是子模块。你兴冲冲地给主仓库地址加上了镜像后缀，速度'嗖'的一下上来了，正暗自窃喜，结果发现子模块的下载速度依然纹丝不动，慢得让人绝望。这是因为子模块的 URL 是独立写在 .gitmodules 文件里的，你改主仓库地址对它没用。于是你又得手动去一个个修改子模块的 URL，项目一多，子模块一杂，这个过程既繁琐又容易出错。我经历过好几次，因为漏改了一个子模块的地址，导致整个构建流程卡住，排查了半天才发现问题所在。
所以，我们真正需要的，是一个持久生效、无需反复折腾系统配置、并且能同时覆盖主仓库和所有子模块的加速方案。它应该像设置一个开关，打开之后，所有通过 git 发起的克隆、拉取操作都能自动'走快车道'，而不需要我们每次去指挥交通。好消息是，这样的方案是存在的，而且实现起来比你想象的要简单得多。它完全基于 Git 自身的配置能力，不依赖任何外部代理或复杂的系统级改动，安全又可靠。接下来，我就带你一步步搭建这个属于你自己的 Git'加速网络'。
2. 核心原理：URL 重写
在深入具体操作之前，我们得先搞明白这个'核心方案'到底是怎么一回事。它的核心思想，叫做 URL 重写（URL Rewriting）。你可以把它想象成 Git 内置的一个'智能地址翻译器'。
通常情况下，当你执行 git clone https://github.com/someuser/awesome-project.git 时，Git 会忠实地按照你给的地址，去 GitHub 的服务器上获取数据。这个链路可能跨越半个地球，速度自然快不起来。而国内的一些公益镜像站（比如 github.com.cnpmjs.org 或 hub.fastgit.org）同步了 GitHub 上的代码，从物理位置上离我们更近，访问速度就快得多。
那么，最笨的办法就是每次手动把命令写成：git clone https://github.com.cnpmjs.org/someuser/awesome-project.git。但这样太麻烦了，而且无法解决子模块的问题。
Git 的 URL 重写功能，允许我们定义一个规则：'每当 Git 遇到以 https://github.com/ 开头的 URL 时，自动把它替换成 https://github.com.cnpmjs.org/'。这个规则是写在 Git 的全局配置文件（~/.gitconfig）里的，对你这台电脑上的所有 Git 操作都生效。
它的工作原理是这样的：
- 你输入的命令依然是原始的 GitHub 地址。
- Git 在执行前，会先检查配置文件中的重写规则。
- 发现匹配的规则（
https://github.com/），于是静默地将目标地址替换为镜像站地址（https://github.com.cnpmjs.org/）。 - 最终，网络请求实际发往的是速度更快的镜像站，但对你而言，整个过程是完全无感的。
这个机制的强大之处在于它的透明性和全局性。它不仅对 git clone 生效，对 git pull、git fetch、git submodule update 等所有涉及网络拉取的操作都生效。更重要的是，对于子模块，Git 在递归处理时，也会自动应用这个重写规则去获取子模块的地址。这就意味着，你只需要配置一次，主仓库和所有层级的子模块就全部自动加速了，真正实现了'一劳永逸'。
3. 快速上手：配置全局 .gitconfig
理论说清楚了，我们直接动手。配置过程非常简单，只需要编辑一个文件。这个文件通常在你的用户家目录下，叫做 .gitconfig（注意开头有个点，在 Linux/macOS 上是隐藏文件）。
3.1 找到并编辑配置文件
对于 Linux 和 macOS 用户： 打开终端，输入以下命令，用你喜欢的文本编辑器（如 nano、vim、VSCode）打开全局 Git 配置文件：
