开发环境越来越慢时，最容易想到的办法是加内存、换更快的硬盘，或者把仓库搬到性能更强的机器。我最近也沿着这条路怀疑过：长任务变慢、Git 维护变多、临时目录越积越多，看起来很像算力和存储不够。
真正把现场拆开后，我得到的结论恰好相反：主要问题不是机器做不动，而是自动化在持续制造本来不该长期存在的工作。一套为了“随时可恢复”而建立的快照机制，把大量临时工作区当成长期对象；这些对象又不断触发扫描、裁剪和仓库维护。机器越努力，浪费反而越稳定。
这次清理让我重新确认了一条顺序：遇到开发环境变慢，先检查工作量是从哪里生成的，再讨论硬件是否不足。
慢的不是一次 Git 命令，而是一条放大链
表面症状通常很分散：打开仓库变慢、后台维护频繁出现、磁盘 I/O 不时升高、工具反复扫描已经结束的目录。单看任何一个症状，都可能被解释成仓库太大或机器太弱。
把事件按因果关系重新排列后，链条就清楚了：
- 自动机制为短期任务创建快照或隔离工作区；
- 任务结束后，这些对象没有明确到期或删除条件；
- 后续扫描把它们继续识别为活动仓库；
- 每个仓库都进入对象整理、裁剪或完整性检查；
- 维护耗时增加，又诱发更多“先做一份快照再处理”的防御动作。
这不是一个慢命令，而是生产者、存量和维护器相互放大的循环。如果只优化最后一步，例如调低 Git 垃圾回收频率，前面的无边界生产仍会继续。
Git worktree 本来是临时隔离能力，不是永久任务仓
Git 官方文档说明，一个仓库可以有主工作区和多个关联工作区；关联工作区共享仓库数据，但拥有自己的 HEAD、索引等状态。它非常适合在不打扰当前开发的情况下做修复、试验或审查。[1]
关键是生命周期。官方文档直接建议：关联工作区使用结束后，通过 git worktree remove 移除；若目录被手工删除，遗留的管理信息可以由 git worktree prune 清理。[1]
因此，worktree 数量多不是原罪。真正危险的是它没有回答三个问题：
- 谁创建：是真实并行开发，还是每次运行都自动复制；
- 何时结束：合并、放弃、超时或验收后，哪个事件负责收口；
- 唯一价值在哪：未提交修改、独立分支和可重建缓存不能混成同一种“都先留着”。
没有这三个答案，隔离能力就会悄悄变成永久存储策略。
为什么仓库维护会把问题放大
git maintenance 的目的，是优化仓库数据、加快后续命令并减少存储占用。它不是坏东西。问题在于，优化工作会随着仓库规模和对象数量增长，其中完整 gc 需要重新打包对象，官方明确提醒它对大型仓库可能很昂贵。[2]
官方文档还说明，同一仓库的维护任务会竞争对象数据库锁；如果维护窗口过长，应降低任务复杂度，或者减少高成本任务的执行频率。[2]
这解释了一个常见误判：看到维护慢，就继续给维护器加计划、并发或重试。可如果真正的输入是一批无人使用的仓库和工作区，维护器越勤快，只会越频繁地为垃圾做正确工作。
我采用的清理顺序：先停生产者，再碰存量
这次我没有从删除目录开始，而是按四步收口。
第一步：停止继续生成
先关闭自动快照和自动登记入口，确认新的临时任务不再被长期收录。否则一边清理、一边生成，最后只会得到一张短暂好看的数字截图。
第二步：按生命周期分类
我把现场分成四类：
- 正在使用的主工作区；
- 仍有明确负责人和用途的隔离工作区；
- 已经完成、可由 Git 重建的临时现场；
- 含唯一未提交内容、需要先保全的异常现场。
真正需要保护的是第四类，而不是“所有目录”。对无法立即判断的少量对象，先进入独立冷存档，比把整批旧现场继续挂在活动扫描面更安全。
第三步：使用对象自己的删除方式
关联工作区优先使用 git worktree remove；目录已经消失时，再用 git worktree prune --dry-run 预览并清理陈旧管理信息。普通缓存、快照仓和孤立目录则按它们各自的 owner 处理，不把 rm -rf 当成通用生命周期工具。
第四步：验证浪费不再产生
清理完成不等于修复完成。我继续观察了三个结果：活动工作区是否保持稳定、后台是否停止新建无价值仓库、对象缺失和重复维护错误是否继续出现。只有生产入口与后续症状同时安静下来，才能说明根因被截断。
什么时候才应该升级硬件
我并不反对加内存或换更快的盘。硬件升级适合解决的是真实、必要而且不可通过生命周期治理消除的工作量，例如大型编译、真实并发测试、数据库负载或模型推理。
在采购之前，我现在会先问四个问题：
- 高负载来自当前有人使用的任务，还是无人消费的自动化；
- 删掉可重建缓存后，核心工作仍然慢吗；
- 瓶颈是 CPU、内存、磁盘、网络，还是对象数量与调度冲突；
- 扩容会缩短真实交付时间，还是只让垃圾积累得更快。
这四问不会否定硬件价值，却能避免用长期成本掩盖软件生命周期缺口。
适用边界
不是所有快照都应该关闭。数据库一致性备份、不可重建的运行数据、发布回滚点和含唯一未提交内容的现场，都有明确保留价值。本文针对的是可重建、无人消费、没有到期条件，却被持续纳入活动维护的开发临时对象。
我这次最大的收获，不是把工作区数量降下来，而是确认了一个更通用的判断：自动化的价值不能只看“它能不能生成”，还要看生成物是否有人消费、何时退出，以及维护成本由谁承担。开发环境变慢时，先清理错误的工作量，再决定要不要升级机器，往往比盯着资源曲线更接近根因。
本文来自一次真实开发环境效率整治，使用 AI 辅助结构化与校对；机器、目录、项目、仓库数量、内部工具和运行记录均已匿名化。
来源与核验
- Git 官方文档：git-worktree（核验于 2026-09-03；页面标注最新更新版本 2.54.0）
- Git 官方文档：git-maintenance（核验于 2026-09-03；页面标注最新更新版本 2.54.0）
