Git工作区文件一键还原的本质是git restore；VSCode 1.56+默认调用git restore而非git checkout，因后者易误触发分支切换，git restore --worktree为VSCode默认“Discard Changes”行为。
Git 工作区文件一键还原的本质是 git checkout 还是 git restore？
VSCode 本身不直接执行 Git 还原操作，它调用的是你系统里配置的 Git 命令。VSCode 1.56+ 默认使用 git restore（Git 2.23+ 引入），而不是旧的 git checkout —— 因为后者在处理路径时容易误触发分支切换，尤其当你有未跟踪文件或文件名和分支名相同时，git checkout file 可能被解释成 git checkout branch，直接切错分支。
-
git restore --staged --worktree：同时丢弃暂存区和工作区修改（即“彻底还原”） -
git restore --worktree：只还原工作区，保留暂存区（VSCode 默认右键「Discard Changes」行为） - 如果 Git 版本 git checkout -- <file>，但该命令无法安全批量还原含空格或特殊字符的路径
VSCode 内如何真正「一键还原所有已修改文件」？
VSCode 没有内置的「整个工作区一键还原所有修改文件」按钮，所谓“一键”实际要分两步手动触发，且必须确认范围——否则可能误删刚写的代码。
- 打开源代码管理视图（
Ctrl+Shift+G/Cmd+Shift+G） - 点击「CHANGES」标题右侧的 三个点 → 选择
Discard All Changes - 弹窗出现时，注意看顶部提示：它只会还原
Working Tree Changes（即未git add的修改），不会碰已暂存的文件 - 如果想连暂存区一起清掉，得先在终端运行
git reset --hard，再点Discard All Changes，否则 VSCode 不会主动调用--staged
为什么点了「Discard All Changes」后某些文件没被还原？
常见不是 VSCode 问题，而是 Git 状态判断逻辑导致的“视觉遗漏”：
- 文件被
.gitignore忽略但已被 Git 跟踪（即曾提交过）：仍会出现在 CHANGES 列表，可被还原 - 文件被
.gitignore忽略且从未被 Git 跟踪：不会出现在列表里，VSCode 根本看不到，自然不会还原 - 文件权限变更（如
chmod）、换行符差异（CRLF/LF）：默认不显示为修改，除非设置了core.filemode=true或core.autocrlf=false - 子模块目录内有修改：VSCode 主工作区的「Discard All Changes」不递归处理子模块，需单独进子模块目录操作
想脚本化或终端快速还原全部？别用 git checkout .
虽然 git checkout . 看起来最短，但它在 Git 2.23+ 已被标记为“不推荐”，且行为不一致；更安全、明确的方式是：
git restore --staged --worktree --source=HEAD -- .
说明：
-
--source=HEAD显式指定还原来源，避免因当前分支 detached 或 reflog 缺失导致意外行为 - 末尾的
.表示当前目录及子目录，不会跨到父级或子模块 - 如果只想还原某类文件，比如所有
.ts文件：git restore --staged --worktree --source=HEAD -- '*.ts'（注意引号防止 shell 展开） - Windows 用户注意：PowerShell 中通配符需用双引号
"*.ts"，CMD 则不用
还原不可逆，没有回收站。哪怕只是改了三行，也建议先扫一眼「Source Control」面板里的文件列表——VSCode 不会替你读心，它只按 Git 状态执行命令。
