<p>git checkout -- 只对已跟踪文件生效，对未跟踪文件静默失败；git restore 更安全明确，但需 Git 2.23+，旧版仍需 git checkout -- 或 git checkout HEAD --。</p>
git checkout -- 恢复单个文件时为什么有时没反应
因为 git checkout -- 只作用于已跟踪（tracked）的文件。如果文件是新创建且未 git add 过，它不在暂存区，也不在 Git 历史里，这条命令会静默失败——终端不报错，但文件内容不变。
- 先确认文件状态：
git status看是否显示在 “Changes not staged for commit” 下；若显示在 “Untracked files” 下，git checkout --无效 - 对未跟踪文件，直接删掉即可：
rm <file>或手动删除 - 别把
--漏掉：写成git checkout <file>（没双横线）可能切换分支，误操作风险高
git restore 是不是比 git checkout -- 更安全
是，但得看 Git 版本和意图。git restore 是 Git 2.23+ 引入的明确语义命令，专为“丢弃工作区修改”设计，不会意外切换分支或检出提交。
-
git restore <file>等价于旧版git checkout -- <file>，但更直白 - 想同时清暂存区和工作区？用
git restore --staged --worktree <file> - Git 2.22 及更早版本不支持
git restore，强行使用会报错：unknown subcommand 'restore' - 部分老旧 CI 环境或公司镜像仍用 Git 2.18，上线前建议查一下：
git --version
撤销所有工作区修改但保留新增文件
用 git restore . 最稳。它只处理当前目录下已被 Git 跟踪的文件，忽略未跟踪项（比如刚写的 temp.log 或 debug.js），不会误删。
- 别用
git checkout -- .—— 语义模糊，老手也容易手滑 - 如果执行后发现不该恢复的文件也被改了，立刻
git fsck --lost-found找悬空对象（但成功率低，不如提前git stash） - 想预览影响范围？加
--dry-run参数（仅 Git 2.35+ 支持）：git restore --dry-run . - 注意路径：在子目录里运行
git restore .只影响该目录，不是整个仓库
误删了刚改完还没 commit 的文件怎么办
只要文件曾被 git add 过（哪怕只是暂存过一次），就能从暂存区捞回来；否则只能靠系统回收站或编辑器本地历史。
- 检查暂存区有没有：
git ls-files --stage | grep <filename>，有输出说明还在索引里 - 从暂存区还原：
git restore --source=HEAD --worktree <file>（Git 2.23+）或git checkout HEAD -- <file>（兼容旧版） - 如果连暂存区都没，但编辑器支持本地历史（如 VS Code 的 “Local History” 扩展），那是最后防线
- Git 不保存工作区快照，也没“回收站”机制——这点和 SVN 或 IDE 自带版本不同，得自己建立习惯
Git 的撤销动作不保存中间态，一旦 restore 或 checkout -- 执行完成，原内容就从工作区消失了，没有二次确认，也没有撤回命令。
