科技 · 实用指南
Git 报“object file is empty”？删除前先保全对象 ID
零字节 loose object 是仓库证据，不是清理目标。先停止写入、保存完整对象 ID 与 .git、盘点损坏，再从可信副本恢复精确对象或抢救仅本地工作。
“object file … is empty”表示 loose-object 路径存在，但 Git 无法从中读取有效对象。把完整 OID 与周围仓库当作证据；不要先批量删除空文件、reset --hard 或覆盖整个 .git。
停止 Git 写入，把工作树与 .git 复制到不同存储，记录精确 OID，再做只读盘点。恢复方案取决于对象类型、可达性，以及远端、独立克隆、alternate 或备份中是否有可信副本。
停止写入并保全证据
停止编辑器、IDE Git 集成、后台同步和维护。保存完整报错、仓库路径、完整 OID、可取得的 status，以及崩溃、断电、磁盘满或文件系统异常。
把工作树和 .git 复制到不同存储。按完整 OID 保存零字节路径，而不是删除。服务器 bare 仓库应先停写并走平台维护与备份流程。
修复前先盘点
在保全副本上运行 git fsck --full，并在需要排除 reflog 根时另存 --no-reflogs 输出。把 missing、bad、dangling、unreachable 分开记录。
检查 alternates、pack、refs 与 reflogs，确认是单个 loose object 还是多对象。边界不明时不要 gc、prune、reset --hard 或批量删空文件。
分类 OID 并寻找可信副本
用 fsck 的引用链判断对象是 blob、tree、commit 还是 tag。blob 可由引用 tree 与 git ls-tree 定位路径；commit 与 tree 的结构恢复更难。
在独立克隆、远端、bundle、备份和 alternate 中核对完整 OID。只有确认远端有该对象且本地历史已保全，普通 fetch 才适合。
选择破坏最小的恢复
若可信来源有精确对象，通过干净的 Git 路径或备份恢复，再验证 OID 并重跑 fsck。不要用另一仓库的整个 .git 覆盖。
若 missing blob 可从已知版本重建，先对副本运行 git hash-object；只有 OID 完全一致才写入。否则把工作树抢救到新克隆，同时保留损坏仓库。
验证仓库与存储
fsck 不再报告可达对象缺失或损坏、refs 可解析、预期历史和工作树修改仍在、全新独立克隆可检出，才算恢复；只有 dangling 输出可能正常。
若损坏复发、更多对象失败或出现 I/O、内存、电源、文件系统异常，停止仓库手术并检查存储。确认新克隆与全部本地改动前保留两份备份。
