git stash drop 不会立即删除磁盘对象，仅移除 refs/stash 引用和 reflog 条目；底层 commit 仍保留在 .git/objects/ 中，需 git gc --prune=now 才真正释放空间。
stash drop 会真正删除磁盘上的对象吗？
会，但有前提：git stash drop 本身只移除 refs/stash 引用和对应 reflog 条目，底层的 commit 对象不会立刻被删——Git 的垃圾回收（git gc）才会真正释放物理空间。如果你刚执行了 git stash drop 却发现磁盘占用没变，不是命令失效，而是对象还躺在 .git/objects/ 里，等着被 GC 清理。
实操建议：
- 先确认要删的是哪个 stash：
git stash list，输出形如stash@{0}: WIP on main: abc1234 feat: add logging - 删指定项用
git stash drop stash@{2}；删最新一个直接用git stash drop - 删完后运行
git gc --prune=now强制触发清理（尤其在 CI 或本地空间紧张时） - 注意：GC 会压缩对象并重写 packfiles，可能短暂占用 CPU 和 I/O，避开高峰期操作
误删 stash 后还能恢复吗？
能，只要还没执行 git gc --prune=now 或时间未超 reflog 过期阈值（默认 30 天）。Git 的 stash 本质是普通 commit，被记录在 reflog 中。
实操建议：
- 查 reflog 中所有 stash 相关记录：
git reflog | grep stash - 找到对应 hash（如
abcd123），用git stash apply abcd123恢复 - 或者更稳妥地重建 stash：
git stash store -m "recovered" abcd123 - 如果已 GC 过，且没备份，基本不可逆——stash 不进远程仓库，也不参与 push/fetch
为什么 git stash pop 后再 drop 会报错？
因为 git stash pop 默认等价于 apply + drop，它会在成功应用后自动删除该 stash。如果你紧接着对同一个索引再执行 git stash drop stash@{0}，就会提示 fatal: Needed a single revision 或 “No stash found”。
常见错误现象：
-
git stash pop成功后，git stash list已为空，此时再drop必然失败 -
pop过程中发生冲突未解决，Git 不会自动 drop，这时stash@{0}仍存在，可手动drop - 想安全弹出并确认后再删？改用
git stash apply && git stash drop分两步，便于检查结果
大量 stash 积压时，批量清理的最佳实践
长期不用的 stash 会拖慢 git stash list、增加 GC 压力，甚至干扰 git log --grep 等搜索。别靠肉眼数着删。
实操建议：
- 按时间批量清理：保留最近 7 天的，删更早的 ——
git stash list --date=iso | awk '$4" "$5 /dev/null - 按消息关键词过滤删：
git stash list | grep -i "wip\|temp\|debug" | cut -d: -f1 | xargs -I{} git stash drop {} - 删前务必确认：
git stash list输出重定向到文件留痕，例如git stash list > /tmp/stash-before-drop.log - 脚本中慎用
-q（quiet），静默模式下失败不报错，容易误清
真正影响磁盘空间的从来不是 stash 列表本身，而是那些没人引用的 commit 对象。reflog 一过期、GC 一跑完，它们就彻底消失——所以别只盯着 list 输出，得盯住 .git/objects/ 的实际大小变化。
