git restore filename可直接恢复未暂存的误删文件，前提是文件曾被git跟踪且未git add删除操作；执行后文件立即回归工作区，含空格路径需加引号。
git restore 能直接恢复未暂存的误删文件
文件刚被 rm 删除、还没运行 git add，且原本被 Git 跟踪（即曾 git add 并 git commit 过），这时 git restore filename 是最直觉有效的操作。它从暂存区还原文件到工作区，不碰提交历史，也不要求你记住分支名。
- 执行
git status后看到deleted: src/main.js，但该行不在Changes to be committed区域 → 属于这种情况 - 直接运行
git restore src/main.js，文件立刻回到工作区 - 路径含空格或特殊字符必须加引号：
git restore "docs/read me.md" - 想预览影响，先加
--dry-run：git restore --dry-run src/*.ts
git checkout HEAD -- 是旧版 Git 或已暂存删除时的兜底方案
如果你用的是 Git 2.22 或更早版本，git restore 会报 unknown command；或者你已经 git add 过删除操作（git status 显示 deleted: 出现在 Changes to be committed 下），就必须用 git checkout HEAD -- filename。
-
--绝对不能省，否则 Git 可能误判为切换分支，比如git checkout HEAD README.md在存在README.md分支时真会切过去 - Windows 下路径含空格，
filename必须加引号：git checkout HEAD -- "src/utils.ts" - 该命令无条件覆盖工作区同名文件（即使你刚新建了一个），Git 不做内容比对
- 若当前不在默认分支，可把
HEAD换成具体分支名，如git checkout main -- package.json
已 git add 删除后，得先 git reset HEAD 再恢复
你手动 rm file.txt，又执行了 git add file.txt，Git 就把“删除”记进了暂存区。此时文件已从工作区消失，但还没 commit —— 这时候不能直接 git restore 或 git checkout --，得先撤回暂存。
- 运行
git status，若deleted: file.txt出现在Changes to be committed下 → 属于这种情况 - 先执行
git reset HEAD file.txt：暂存区删除记录被取消，git status会立刻变成deleted: file.txt移到Changed but not updated区域 - 再执行
git checkout -- file.txt或git restore file.txt即可还原 -
git reset HEAD只操作暂存区，不影响工作区，和git reset --hard完全不是一回事
文件名匹配失败？检查三件事
运行 git checkout -- filename 或 git restore filename 报错 pathspec 'xxx' did not match any file(s) known to git，通常不是命令写错，而是前提条件没满足。
- 文件从未被 Git 跟踪过（即没
git add过、也没git commit过）→ Git 根本不知道它存在，无法恢复 - 你删的是刚
git add但还没git commit的新文件 → 它只在暂存区有，工作区删了就真没了，git restore会从暂存区拉，但前提是暂存区还有内容 -
git status没显示deleted:→ 可能文件根本没被 Git 管理，或你删的是.gitignore里排除的路径
最容易被忽略的一点：Git 不感知 rm，只靠 git status 推断状态。看到 deleted: 就立刻操作，别等、别补 git add .，那会把删除动作真正记进暂存区，让恢复多一步甚至失效。
