git 2.30+ 的 sparse-index 功能需配合 cone 模式下的 sparse-checkout 才能生效，它通过精简索引仅保留指定路径条目，将百mb级索引压缩至几mb，使 monorepo 中 git checkout 等操作回归毫秒级响应。

Git 2.30+ 的 sparse-index 功能能显著加速 monorepo 中的 git checkout，但它不是自动开启的，必须配合 sparse-checkout 启用，且仅对已启用 cone 模式的稀疏检出生效。

为什么 git checkout 在 monorepo 里慢得反常

不是磁盘 I/O 或网络问题，而是 Git 默认为每个 tracked 文件维护 index 条目（即使你根本不用它）。50 万个文件 → index 文件可能超 100MB，git checkout 必须遍历、比对、重写整个 index。尤其在 monorepo 中频繁切换分支时，这个开销会直接卡住命令响应。

常见现象包括：

• git checkout feature/x 卡住 3–8 秒，git status 也明显变慢
• git add . 误触大量本不该参与当前开发的子目录文件
• VS Code 的 Git 面板长时间显示“Refreshing…”

sparse-index 不是独立开关，它依赖 sparse-checkout 的 cone 模式

Git 不会因为你装了 2.30+ 就自动启用 sparse-index。它只在满足以下全部条件时激活：

Git Monitor

通用Git项目监控工具，支持GitHub、GitLab、Gitee等平台。可增删仓库、检查更新、自动拉取代码并生成变更摘要。用于“监控项目”“检查更新”“添加仓库”等场景。

下载

• 已启用 sparse-checkout（即 .git/info/sparse-checkout 存在且非空）
• 使用 cone 模式（core.sparseCheckoutCone=true，Git 2.25+ 默认开启）
• 检出路径符合 cone 规则（如 src/app/**、packages/cli/**，不能写 **/test.js 这类非前缀匹配）

验证是否生效：

git ls-files --sparse | wc -l  # 输出应 ≈ 你实际需要的文件数，而非仓库总文件数
git ls-files | wc -l            # 输出仍为全量，但 index 内部只存 sparse 路径

实操：三步启用 sparse-index 加速分支切换

假设你要专注 packages/web 和 shared/utils：

• 确保 Git ≥ 2.30：git --version，低于则升级
• 启用 cone 模式并设置规则：

  git config core.sparseCheckoutCone true
  echo "packages/web/**" > .git/info/sparse-checkout
  echo "shared/utils/**" >> .git/info/sparse-checkout

• 重置工作区以触发 sparse-index 构建：git read-tree -mu HEAD（注意：这会丢弃未提交更改，先 git stash）

之后每次 git checkout 只处理你声明的路径，index 大小从百 MB 缩到几 MB，分支切换回到毫秒级。

容易被忽略的关键点

sparse-index 是 index 层的优化，它不减少对象下载（那是 --filter 干的事），也不改变 commit 历史结构；它只让 Git “假装没看见”那些没被 sparse-checkout 显式包含的文件——但这些文件依然存在于 object database 中，git log --all -- packages/web 仍能查到完整历史。如果你在 CI 脚本里依赖 git ls-files 列出所有源码路径，就得改用 git ls-files --cached 或绕过 sparse 模式临时执行。