git仓库变慢、磁盘占用暴增主因是无用对象堆积；需先用git count-objects -v诊断，再依情况执行git reflog expire、git gc --prune=now --aggressive或git prune，并手动清理.git/refs/original等残留。
Git仓库变慢、磁盘占用暴增，八成是因为本地积压了大量无用对象——不是你删了文件就真没了，那些历史blob、悬空commit、过期reflog还在.git/objects里躺着。直接上git gc往往治标不治本，甚至可能卡住或跳过清理。关键得先诊断、再分层处理。
怎么判断是不是对象堆积导致的臃肿
别猜，用git count-objects -v看真实数据。重点关注size（松散对象大小）和size-pack（打包对象大小）两项：
- 如果
size> 100MB 且远大于size-pack，说明有大量未打包的loose objects，git gc能快速见效 - 如果
size-pack> 500MB 且in-pack对象数极多，问题大概率出在历史大文件，git gc无效，必须用git filter-repo或bfg - 执行
git fsck --unreachable后输出大量dangling commit或dangling blob，就是悬空对象已泛滥，需立即git prune
git gc --prune=now 和 git prune 的区别与使用时机
git gc是“打包+轻量清理”，git prune才是“硬删悬空对象”的执行者。很多情况下git gc默认不删，得靠--prune=now显式触发：
-
git gc --prune=now：自动打包+立即删除所有不可达对象，适合日常维护；但若仓库存在gc.log报错（如There are too many unreachable loose objects），它会直接退出，必须先git prune -
git prune -n：模拟运行，只打印将被删的对象ID，务必先跑这句确认没误伤 -
git prune（无参数）：真正删除所有git fsck标记为dangling的对象，比--prune=now更彻底，也更危险——它不检查reflog是否还引用着这些对象
为什么 git reflog expire 必须配合 git gc
reflog默认保留90天记录，每条记录都可能让一批旧对象“死而不僵”。比如你git rebase了三次，旧的commit对象仍被reflog引用，git gc就不会动它们：
-
git reflog expire --expire=now --all：立刻清空所有reflog条目（慎用！除非你确定不需要git reflog回溯） -
git reflog expire --expire=7.days.ago --all：只保留最近7天reflog，平衡安全与瘦身 - 必须在
git reflog expire之后立刻跟git gc --prune=now，否则reflog删了但对象还占着空间 - 注意：
git reflog是本地操作，不影响远程，但删完就真不能git reset HEAD@{2}了
清理后空间没降？大概率是 pack 文件没重写
git gc默认复用旧pack，不会压缩或去重。真正瘦身要加--aggressive并强制重写：
-
git gc --aggressive --prune=now：启用深度压缩算法，耗时长但能显著减小size-pack - 更激进的做法：
git repack -adF --window=250 --depth=250，强制重新打包全部对象（-a全打包，-d删旧pack，-F用zstd压缩） - 执行后务必再跑一次
git count-objects -v对比size-pack变化，否则你以为瘦了，其实只是挪了个地方 - 提醒：
--aggressive在超大仓库（>10GB）可能卡住，建议先git clone --filter=blob:none拉个稀疏克隆做测试
最常被忽略的一点：git gc不会碰你本地已删除但尚未git rm的文件残留，也不会清理.git/refs/original/这类filter-branch遗留目录——这些得手动rm -rf .git/refs/original，否则瘦身永远不彻底。
