VS Code 中 stash 与暂存区无关，它是独立保存工作区和暂存区两份状态的快照；默认不包含未跟踪文件，apply 不还原暂存状态，pop 才能删除 stash 条目；图形界面功能有限，关键操作需终端命令。
VS Code 里没有“Stash 暂存区”这个概念——stash 本身是独立于暂存区（index）的临时快照，不是 Git 的 staging area。混淆这点会导致操作错位、恢复失败或丢失修改。
Stash 和暂存区（Stage）根本不是一回事
很多人误以为 git stash 是把文件“暂存到 stash 区”，其实它保存的是工作区 + 暂存区的**两份独立状态快照**：一份是未暂存的修改（working directory），一份是已暂存但未提交的变更（index）。执行 git stash push 后，这两部分都会被剥离出当前工作流，工作区直接回退到上一次 commit 状态。
常见错误现象：
- 执行
git stash后发现某些改动没保存 → 实际是那些改动还没被git add过，但 stash 默认只保存 tracked 文件；新创建的未跟踪文件（untracked）默认不进 stash - 用
git stash apply恢复后，文件显示为“已修改但未暂存”，而你本想保留原来已git add的状态 → 因为apply不还原暂存区，只还原工作区；要用git stash pop或带--index参数才可能还原暂存状态
VS Code 中真正可用的 stash 快捷入口只有三个
VS Code 并未给 stash 操作分配独立快捷键，所有 stash 行为都依赖命令面板或源代码管理视图的上下文菜单。所谓“快捷键”本质是组合动作：
-
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS）→ 输入Git: Stash Changes→ 回车：最常用，等价于git stash push -
Ctrl+Shift+P→ 输入Git: Stash Changes with Description→ 回车：强制弹出输入框，避免无描述的 stash@{n} 条目难以识别 - 在源代码管理视图中点击
⋯（更多操作按钮）→ 选Stashes→ 列表里点Apply或Pop：这是唯一能操作历史 stash 的图形化路径，无法用快捷键直达
注意：Git: Apply Last Stash 命令存在，但它不等价于 git stash pop —— 它只是 apply，不会从栈中删除条目，容易造成重复应用冲突。
想一键 pop 最新 stash？得靠自定义 keybinding
VS Code 默认没绑定 git stash pop 的快捷键，但你可以手动加：
[
{
"key": "ctrl+alt+p",
"command": "git.stashPop",
"when": "scmProvider == 'git'"
}
]
把这个片段加进 keybindings.json（通过 Ctrl+K Ctrl+S 打开快捷键设置 → 右上角打开 JSON）即可。关键点：
-
git.stashPop是 VS Code 内置命令，它调用的是git stash pop，会自动删除被应用的 stash 条目 -
when条件确保只在 Git 仓库中生效，避免全局冲突 - 别用
git.stashApply绑定快捷键——它不删 stash，多次触发会导致同一份修改反复叠加，极易引发冲突
stash list 看不到内容？补丁模式才是真·可读
VS Code 图形界面里的 Stashes 列表只显示 stash@{0} 和简短描述，看不出改了哪几行。真正排查时必须用终端：
-
git stash list：只看条目序号和时间 -
git stash show -p stash@{0}：显示完整 diff，确认是否包含你关心的文件和逻辑 -
git stash show --stat stash@{1}：只看变更文件列表和行数，快速扫描范围
尤其当多人协作或长期 stash 积压时，-p 输出是唯一可靠依据。VS Code 的图形界面在此环节完全不可信。
stash 的核心陷阱从来不在操作多难，而在“以为它和 stage 一样可控”。它实际是脱离 Git 正常提交链的黑盒快照，恢复时的冲突、索引错位、未跟踪文件遗漏，全取决于你当初 push 时有没有加 -u、--keep-index 或 --include-untracked。图形界面藏掉了这些细节，反而最容易出事。
