<p>git checkout 无法直接恢复已删除文件，需先判断删除是否暂存及文件是否被跟踪：未暂存且已跟踪用 git restore filename；已暂存则用 git checkout HEAD -- filename 或 git restore -s HEAD -- filename。</p>
git checkout 无法恢复已删除文件？先确认状态
git checkout 本身不直接恢复工作区被 rm 删除的文件，它只从暂存区（index）或某次提交中检出内容。如果你删了文件但还没 git add 或 git commit，文件其实还在 Git 的对象库里——只是没在工作区显示。
常见错误现象：
- 运行
git checkout -- filename报错error: pathspec 'filename' did not match any file(s) known to git - 文件确实被
rm掉了，但git status显示 “deleted: filename”，说明 Git 已感知删除，但尚未提交
这时要分两种情况处理：
- 如果文件刚删、还没
git add删除记录：用git restore（Git 2.23+）最稳妥 - 如果已经
git add过删除操作（即暂存区标记为 deleted）：得从上一次提交里拉回来
git restore filename 恢复未暂存的删除
这是 Git 2.23 引入的明确语义命令，专为“撤销工作区修改”设计，比 git checkout -- 更安全、意图更清晰。
使用场景：
- 你手动
rm file.js，git status显示 “deleted: file.js”，但没运行git add file.js
实操建议：
- 直接运行
git restore file.js，文件立刻回到工作区 - 想看会恢复哪些文件，先加
--dry-run：git restore --dry-run file.js - 如果误删多个文件，支持通配：
git restore src/*.ts - 注意：该命令默认从暂存区恢复；如果暂存区也没了（比如已
git add删除），就得指定提交：git restore -s HEAD -- file.js
git checkout HEAD -- filename 从最近提交硬恢复
适用于暂存区也“记了删除”的情况，或者你用的是旧版 Git（< 2.23）。
参数差异：
-
HEAD表示最新一次本地提交；也可换成分支名如main、提交哈希如a1b2c3d -
--是分隔符，防止文件名被误认为分支名（尤其当文件名含-时）
容易踩的坑：
- 忘加
--，比如写成git checkout HEAD README.md，Git 可能报错或切到同名分支 - 误删后又新建了同名文件，再执行此命令会直接覆盖——Git 不做内容比对，只按索引替换
- Windows 下路径大小写敏感性可能让
git checkout找不到文件（比如实际是File.js，却输成file.js）
rm 后连 git status 都看不到文件？检查 .gitignore 和跟踪状态
有时删完运行 git status，发现压根没提示“deleted”，文件像凭空消失——大概率它根本没被 Git 跟踪。
性能 / 兼容性影响：
- 未跟踪文件不会进对象库，Git 对它完全无感知，自然无法恢复
-
git ls-files --other --exclude-standard可列出所有未跟踪但未忽略的文件；加--ignored看被忽略的
实操建议：
- 先确认是否曾被跟踪：
git log --oneline --follow -- filename - 查看是否被
.gitignore排除：git check-ignore -v filename - 如果文件本就该被跟踪，但漏加了，恢复后记得
git add filename
Git 恢复误删的关键不在命令多复杂，而在于搞清“删除动作是否进入暂存区”以及“文件是否曾被跟踪”。这两个判断错了，后面所有命令都会绕弯。
