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项目监控工具，支持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 模式临时执行。
