git show-ref 和 git fsck 是诊断工具，不用于修复孤儿对象；dangling blob 是无任何引用的 blob 对象，通常可安全清理。
git show-ref 和 git fsck 本身不用于“修复”孤儿对象，它们是诊断工具；真正的“修复”取决于你是否需要保留这些 dangling blob —— 大多数情况下，它们是安全可清理的垃圾。
理解 dangling blob 的真实含义
所谓 dangling blob，是指 Git 对象数据库中存在、但没有任何引用（commit、tree、tag 或 index）指向它的 blob 对象。它通常来自：
- 未暂存或未提交的文件修改（如编辑后又丢弃）
- git add 后又 git reset --hard 或 git checkout -- 引发的暂存区残留
- rebase/merge 中断后遗留的临时对象
- 手动操作 .git/objects 目录导致的引用断裂
这类对象不会影响仓库功能，但会占用磁盘空间，且可能暴露敏感内容（如误 add 的密钥、日志片段）。
用 git show-ref 定位“可见引用边界”
git show-ref 列出所有**当前有效引用**（branches、tags、remotes 等），但它不直接显示 dangling 对象。它的作用是帮你确认：哪些 ref 是“锚点”，从而反推哪些对象已脱离引用链。
- 运行
git show-ref --heads --tags --dereference查看所有活跃分支与标签的 commit SHA - 结合
git rev-list --all --objects可导出所有被引用的对象路径 - 再与
git fsck --unreachable --no-reflogs输出对比，即可圈定真正游离的 blob
用 git fsck 检测并分类孤儿对象
git fsck 是核心检测命令。注意默认行为会忽略 reflog 中的近期对象（它们虽暂时无 branch 指向，但尚未真正“dangling”）：
-
git fsck --dangling：仅显示 dangling commit / tree / blob（最常用） -
git fsck --unreachable：显示所有不可达对象（含 reflog 已过期的） -
git fsck --no-reflogs：禁用 reflog，让近期“临时”对象也暴露为 dangling - 加
--verbose可看到每个 dangling blob 对应的文件路径（如果能解析）
示例输出：dangling blob a1b2c3d4... (path/to/file.log)
这说明该 blob 曾属于 file.log，但当前无任何 tree 或 commit 包含它。
安全清理 or 有选择恢复？
绝大多数 dangling blob 不值得恢复。若需处理：
-
批量清理：执行
git gc --prune=now（自动清理所有 unreachable 对象，包括 dangling blob） -
查看内容确认：用
git show a1b2c3d4或git cat-file -p a1b2c3d4检查 blob 内容是否敏感 -
单个恢复（极少见）：若确认某 dangling blob 是误删的重要数据，可用
git hash-object -w path/to/recovered重新入库，再手动写入 tree + commit
注意：Git 不提供“一键恢复 dangling blob 到工作区”的命令，因为其原始上下文（路径、权限、归属 commit）已丢失。
