git restore --staged 是当前最安全的取消暂存方式，仅修改暂存区、不触碰工作目录，语义清晰无歧义，支持单文件、多目录及批量操作，并可交互式部分撤销。
git restore --staged 是当前最安全的取消暂存方式
Git 2.23+ 版本起，git restore --staged 是官方明确推荐、语义最清晰的取消暂存命令。它只修改暂存区（index），完全不碰工作区文件内容——哪怕你刚改完 .env 里的密钥，执行后内容原封不动，只是从“Changes to be committed”回到“Changes not staged for commit”。
常见错误现象：有人误用 git checkout -- 或 git reset --hard，结果直接丢掉本地未保存的修改。
-
git restore --staged README.md：取消单个文件 -
git restore --staged src/ utils/：取消多个目录下所有暂存文件 -
git restore --staged '.'：取消当前目录及子目录下所有暂存文件（注意引号，防 shell 展开） - 不支持无参数调用：
git restore --staged会报错，必须指定路径
git reset -- 仍可用，但容易踩坑
git reset -- 在旧版 Git 中广泛使用，本质是把 HEAD 的索引快照覆盖回暂存区。它默认是 --mixed 模式，所以安全；但问题在于语义模糊、易输错。
常见错误现象：漏写 -- 导致 git reset file 被解析为重置分支指针；或手滑写成 git reset --hard，连工作区一起清空。
-
git reset -- README.md：取消单个文件（HEAD 可省略） -
git reset：取消全部暂存，等价于git reset HEAD - 对全新文件（从未提交过）会失败：
pathspec 'xxx' did not match any files - 不支持交互式部分撤销（比如只撤回某几行）
git rm --cached 不是为取消暂存设计的
git rm --cached 的真实用途是“停止跟踪但保留本地文件”，比如要把 .env 从版本库移除又不想删掉它。它只是副作用能清暂存，不是正经撤销操作。
常见错误现象：漏掉 --cached，变成 git rm xxx，真删文件；批量操作时路径写错，误删大量文件。
-
git rm --cached .env：适合从历史中彻底剔除某个文件 -
git rm --cached -r src/：慎用，确认该目录下没有还需跟踪的文件 - 对未跟踪文件（untracked）无效，会提示 “not under version control”
- 执行后需再
git commit才生效，不是即时撤回暂存
VS Code 里点错“暂存”怎么办
VS Code 源代码管理面板右键已暂存文件 → “撤销暂存更改”，等效于执行 git restore --staged <file>。快捷键是选中后按 Alt+Backspace（Windows/Linux）或 Option+Delete（macOS）。
容易忽略的细节：顶部出现的“放弃更改”横幅是丢弃工作区修改，不是取消暂存——点它会直接删掉你刚写的代码。
- 一次性撤回全部？点击“暂存的更改”标题旁的 ⋯ → “撤销所有暂存的更改”
- 撤销后文件自动回到“更改”列表，内容不变
- 如果文件同时在“暂存”和“更改”里（比如先 add 再改），撤销暂存后只退回到“更改”，不会恢复到上次提交状态
实际操作前，先运行 git status 看清当前状态；新项目或不确定 Git 版本时，优先用 git restore --staged，它不依赖 HEAD、不触发重置逻辑、语义唯一。老命令虽能用，但越简单的事，越容易因一个字符输错酿成事故。
