git fsck --full不修复仅诊断，需根据error行定位损坏对象；单个损坏优先git fetch从远程恢复，严重损坏或段错误时应备份工作区后重建.git目录。
git fsck 本身不修复损坏对象，它只报错、定位问题；真正能“救回来”的操作，取决于损坏类型和你手头有没有备份或远程仓库。
git fsck --full 报出 corrupt object 后该看什么
运行 git fsck --full 后，关键不是看有多少 dangling commit（这基本是正常的），而是盯住带 error: 前缀的行：
-
error: loose object xxxxxxxx is corrupt—— 明确指出哪个松散对象文件损坏，路径在.git/objects/xx/xxxxxx -
error: inflate: data stream error—— zlib 解压失败，大概率是文件被截断或磁盘坏道导致 -
error: object file .git/objects/xx/xxxxxx is empty—— 文件存在但大小为 0，常见于强制关机或虚拟机断电 - 如果直接触发
Segmentation fault (core dumped)—— 说明 Git 内部数据结构已错乱，git fsck自身都跑不完了，不能硬扛，得换路子
单个 loose object 损坏：优先尝试 git fetch 或 git reset
多数情况下，损坏对象只是某个旧提交里的 blob 或 tree，而它仍存在于远程仓库。这时别急着删文件，先让 Git 自己“补上”：
- 运行
git fetch --all --prune：强制从所有远程拉取最新引用和缺失对象 - 如果知道损坏对象属于某分支（比如
origin/main），用git fetch origin main更精准 - 拉取成功后，试
git reset --hard origin/main（确保先git stash本地未提交修改）—— 这会重置 index 和工作区，并强制用远程对象覆盖本地损坏部分 - 避免直接
git prune --expire now：它会无差别删掉所有 unreachable 对象，包括你还没来得及恢复的 dangling commit
对象损坏严重或 git fsck 崩溃：放弃修复，重建 .git 目录
当 git fsck 自身段错误、git status 直接退出、或者 .git/objects 下一堆空文件时，说明底层存储结构已不可信。此时继续折腾内置命令只会浪费时间：
- 先把当前代码目录里所有未
git add的修改、新文件，复制到外部临时目录（cp -r ./src ./backup-src） - 删掉整个
.git目录：rm -rf .git - 重新初始化并关联远程：
git init && git remote add origin <your-remote-url> - 用
git fetch --unshallow（如果是浅克隆）或git fetch --depth=1000拉全量历史 - 检出原分支：
git checkout -b main origin/main，再把刚才备份的修改粘回去 - 注意：VSCode Remote-SSH 环境下，务必先关掉 Git 插件再操作，否则它可能在后台持续扫描损坏的
.git，加剧不稳定
最容易被忽略的一点：Git 的对象校验发生在每次读取时，不是写入时。所以一个损坏对象可能蛰伏数天，直到某次 git log --graph 或 git blame 才暴露——定期 git fsck --no-dangling（不输出 dangling）跑一次，比等崩溃后再抢救成本低得多。
