我来帮你解决RestBed仓库克隆时git submodule update --init --recursive耗时过长甚至卡住的问题，这是我在处理类似场景时总结的几个有效方案：

方案一：替换子模块远程源为更快的镜像 #

如果是因为原仓库地址访问速度慢导致的卡顿，可以修改子模块的远程配置：

• 先查看当前子模块的状态和配置：

  git submodule status
  

• 编辑项目根目录下的.gitmodules文件，把dependency/asio、dependency/catch、dependency/openssl对应的url字段替换为访问速度更快的镜像源
• 同步修改后的配置到本地：

  git submodule sync
  

• 重新执行子模块初始化和更新：

  git submodule update --init --recursive
  

方案二：手动逐个克隆子模块 #

批量更新容易因为单个子模块卡住导致整个流程停滞，手动逐个克隆更可控：

• 先在项目根目录创建子模块存放目录：

  mkdir -p dependency
  

• 分别克隆三个子模块到对应路径：

  git clone <asio仓库地址> dependency/asio
  git clone <catch仓库地址> dependency/catch
  git clone <openssl仓库地址> dependency/openssl
  

• 回到项目根目录，让Git识别已手动克隆的子模块：

  git submodule update
  

方案三：使用浅克隆减少下载量 #

如果不需要子模块的完整历史提交记录，可以用浅克隆只拉取最新版本，大幅提速：

git submodule update --init --recursive --depth 1

补充说明 #

这种卡顿通常是因为原GitHub子模块仓库的网络访问速度不稳定，或者需要下载的历史数据量过大导致的。上面的方案分别从优化访问源、拆分操作、减少数据量三个角度解决问题，你可以根据自己的网络环境选择最合适的方式。

内容的提问来源于stack exchange，提问作者Liju Mathew