Windows崩溃后，如何用Git检查工作目录中损坏的文件？

云上老周

2026-7-2

解决Windows断电后Git工作区文件损坏检测与高效恢复问题

Git状态检测的底层逻辑

git status默认采用快速检测：先对比文件的修改时间（mtime）和文件大小，只有这两个属性变化时，才会计算文件哈希并与索引中的记录对比。如果文件内容因损坏被篡改，但修改时间和大小恰好没变，git status会无法识别这种损坏。
若要强制Git对所有文件做逐位哈希对比，执行命令：
```
git status --no-skip-worktree-check
```
该命令会跳过快速检测逻辑，直接计算工作区每个文件的哈希值，与索引及仓库中的对应对象逐一比对，能精准发现内容损坏但属性未变的文件。

普通Git命令仅处理LFS指针文件，无法检测实际大文件的损坏。需执行：

git lfs status --full

此命令会验证本地LFS文件的实际内容哈希是否与仓库记录一致，确保大文件未因断电损坏。

定向修复损坏文件：先用上述检测命令定位出损坏的文件路径，再执行：
```
git checkout HEAD -- <损坏文件的路径>
```
直接从仓库拉取对应文件的正确版本，仅修复问题文件，避免全量克隆的耗时。
一键重置工作区：若无法确定具体损坏文件，且无需要保留的本地未提交修改，执行：
```
git reset --hard HEAD
```
将工作区所有文件强制重置为当前HEAD指向的仓库版本，快速恢复到干净状态。
修复LFS大文件：如果检测到LFS文件损坏，执行：
```
git lfs pull
```
仅重新拉取损坏的LFS对象，比全克隆更节省带宽和时间。