Git仓库报“corrupt loose object”错误本质是.git/objects/中存在0字节空文件，修复需两步：先用find .git/objects/ -type f -empty定位并删除空对象，再执行git fetch -p origin补全缺失对象；未备份前严禁直接rm -rf .git/objects/，且修复后须以git fsck --full无error、无missing警告及能正常git log/checkout所有分支为成功标志。
这个错误不是 Git 坏了，而是本地 .git/objects/ 里混进了空文件（0 字节），Git 读取时直接崩溃。修复核心就两件事：删空文件 + 补对象，不能只做一半。
怎么快速定位哪些 object 文件是空的
别手动翻 .git/objects/ 子目录——它按哈希前两位分层，路径太深。直接用 find 扫描：
find .git/objects/ -type f -empty
输出类似：.git/objects/20/6e7330a25fe1f1e533b5f769103e37e2a5c7f4，这就是损坏对象的完整路径。注意：该命令不报错也不输出，说明没找到空文件；有输出才需要处理。
- 如果终端卡住或报 permission denied，加
2>/dev/null忽略权限错误 - 某些系统上
-empty不可用，换成-size 0 - 千万别在没备份时直接
rm -rf .git/objects/——那等于删掉整个 Git 数据库
删完空文件后为什么 git fetch 还失败
因为 git fetch 默认只拉取当前分支涉及的对象，而空文件可能属于其他分支、tag 或 reflog 记录。必须加 -p（prune）参数清理过期远程引用，并配合 --all 或显式指定远程名：
git fetch -p origin
- 不加
-p：旧的坏引用还在，git fsck仍会报 “ref points to invalid object” - 只运行
git fetch：可能根本不动那些已损坏分支的对象，fetch 成功但问题依旧 - 如果你用的是非默认远程名（比如
upstream），要把origin换成对应名字
git fsck --full 报 warning 但没 fatal，算修好了吗
不算。warning 如 missing blob XXX 或 unreachable commit YYY 是残留痕迹，说明对象没补全。真正修好的标志是：
-
git fsck --full输出只有Checking object directories: 100% (256/256), done. - 没有
error:、fatal:，也没有missing类警告 - 能正常
git log、git checkout所有本地分支
如果仍有 warning，大概率是远程仓库本身缺失对象（比如有人 force-push 覆盖过历史），这时只能联系团队确认是否允许从备份恢复，或接受部分历史丢失。
什么时候必须重 clone，而不是修
当 find .git/objects/ -type f -empty | wc -l 返回值超过 20，或 git fsck --full 反复出现不同 hash 的 missing 对象，基本可判定本地仓库已深度损坏。此时继续修只是浪费时间：
- 先备份工作区：
cp -r . ../myproject-backup（注意不带.git） - 删掉整个项目目录：
rm -rf myproject - 重新
git clone，再把备份里的修改复制回去 - 别跳过
git clone直接git init + git remote add——那样不会重建 packfiles，空文件隐患仍在
最常被忽略的一点：所有修复操作前，一定要 cp -a .git .git-bak-$(date +%s)。Git 本身不提供 undo，误删关键 ref 或 index 文件，连重 clone 都救不回你刚写的代码。
