pack file corrupt 错误表明.git/objects/pack/下的压缩包损坏，无法解压或校验失败；直接删除pack文件可能导致仓库彻底不可用，因松散对象可能已被gc清理；根本原因多为磁盘写入中断、SSD坏块或NFS掉线；git fsck --full会卡在inflate: data stream error，且git gc、git prune、git verify-pack均会失败；安全修复路径是删除全部pack相关文件后执行git fetch --unshallow或git fetch --depth=1000重建pack；若远程pack也损坏，则需rsync备份工作区后全新克隆并手动恢复修改。
pack file corrupt 错误不能靠删文件硬修，它意味着 Git 的压缩对象包（.git/objects/pack/*.pack）已损坏，无法解压或校验失败。直接删 pack 文件可能让仓库彻底不可用——因为松散对象（loose object）早已被 gc 清理，只剩 pack 里存着关键历史。
为什么 git fsck --full 会卡在 inflate: data stream error
这个错误不是“某个文件打不开”，而是 Git 在尝试解压 .pack 文件时 zlib 报错，常见于：inflate: data stream error 或 bad pack header。根本原因通常是磁盘写入中断（如强制关机）、SSD 坏块、或 NFS/网络挂载盘异常掉线。此时 git fsck 自身会反复读取损坏的 pack，卡死或段错误，--full 不会跳过，也不会修复。
- 别运行
git gc或git prune：它们依赖 pack 完整性，会直接失败或加剧损坏 -
git verify-pack -v无法执行：该命令本身就要先解压 pack，一碰就崩 - 远程 fetch 通常无效：如果损坏的是本地 pack，而远程尚好，但 Git 默认不会主动重拉 pack，除非你触发完整重新获取
重建 pack 的安全路径：先清空再 fetch --unshallow
当确认是 pack 损坏（而非 loose object），且你有可用的远程仓库时，最稳的方式是废弃当前 pack，让 Git 从远程完整重建：
- 进入仓库根目录，删掉所有 pack 相关文件：
rm -f .git/objects/pack/*.pack .git/objects/pack/*.idx .git/objects/pack/*.keep - 运行
git fetch --unshallow（如果是浅克隆）；否则用git fetch --depth=1000强制拉取足够深的历史，Git 会自动下载新 pack 并重建索引 - 验证是否恢复：
git fsck --no-dangling应无 error；git log -n 5能正常输出 - 注意：此操作不丢工作区文件，也不影响未提交修改，但会重置
.git/FETCH_HEAD和 reflog，本地分支指针仍指向原 commit
远程也损坏？用 git clone --no-checkout + rsync 差量恢复
如果 git fetch 本身报 fatal: protocol error: bad pack 或连接后立即断开，说明远程 pack 同样损坏（少见但可能，比如 Gitee 仓库被误删 pack 后未 gc）。此时本地修复无意义，必须换源：
- 备份当前工作区全部未提交内容：
rsync -av --exclude='.git' ./ /tmp/repo-backup/ - 全新克隆：
git clone --no-checkout <remote-url> /tmp/new-repo</remote-url>（--no-checkout避免检出时触发损坏 pack 解压） - 进新仓库，手动检出所需分支：
cd /tmp/new-repo && git checkout main，再把/tmp/repo-backup里的修改复制进去 - 切忌用
cp -r复制整个旧目录：.git 里残留的损坏 pack 可能被新 Git 进程再次加载
pack 文件一旦损坏，就没有“局部修复”概念——它不像 ZIP 那样能跳过坏块解压。Git 的 pack 是连续二进制流，头部损坏或中间字节翻转，整个包即不可用。所以所有“删 pack 后 git pull”的方案，本质都是放弃旧数据、信任远程、重建信任链。真正容易被忽略的点是：别在损坏状态下继续做任何 git add 或 git commit，因为新提交的对象可能被错误地打包进同一个坏 pack，扩大污染面。
