在 VSCode 中触发 Git Stash 需右键修改文件选“Stash Changes...”或用命令面板执行“Git: Stash Changes”，注意当前是否含暂存更改以决定是否弹窗；恢复时用“Git: Apply Stash”或“Git: Pop Stash”，建议优先试用 Apply。
怎么在 VSCode 里触发 Git Stash
VSCode 的 Git 面板本身不提供独立的「Stash」按钮，但 stash 功能已深度集成在源代码管理视图的操作流中。关键不是找按钮，而是理解它藏在哪几个交互节点里。
常见错误现象：Ctrl+Shift+P 搜 Git: Stash 没反应？—— 很可能你当前工作区没打开 Git 仓库，或未启用 Git 扩展（默认已启用，但禁用后会消失）。
- 确保左侧活动栏点击了 源代码管理 图标（分支图标），且右上角显示当前分支名（如
main） - 右键任意已修改文件 → 出现
Stash Changes...菜单项（注意是省略号，表示有弹窗） - 或者按
Ctrl+Shift+P（macOS 为Cmd+Shift+P），输入Git: Stash Changes，回车后会提示输入 stash 描述（可空） - 执行后，修改会从工作区和暂存区同时移除，
git status显示干净，但可通过git stash list查到记录
为什么点「Stash Changes」后没弹出输入框
VSCode 默认行为是：如果当前只有「未暂存的更改」（即没 git add 过），它会直接执行 git stash push -m "..."；但如果已有部分改动被 git add 进暂存区（staged），它就必须弹窗让你选「Stash including staged changes」还是「Stash only untracked and modified」——否则语义不明确。
- 容易踩的坑：手动执行过
git add .后再点菜单，VSCode 会卡在弹窗等待选择，但窗口可能被其他面板遮挡（尤其多窗口时） - 解决方法：留意右下角状态栏是否出现「Stash changes」提示，或切到终端看是否有阻塞进程
- 参数差异：
Git: Stash Changes对应git stash push，而旧命令git stash save已废弃，VSCode 不支持
恢复 stash 时选错条目导致覆盖当前修改
VSCode 的 stash 恢复入口藏得更深：必须先打开命令面板（Ctrl+Shift+P），搜 Git: Apply Stash 或 Git: Pop Stash。二者区别直接影响是否留底：
-
Git: Apply Stash=git stash apply：应用后 stash 仍保留在栈中，适合试还原 -
Git: Pop Stash=git stash pop：应用后自动删除该 stash，一旦冲突失败，stash 也丢了 - 容易踩的坑：执行
Pop时 VSCode 不二次确认，如果当前工作区有未提交修改，且与 stash 冲突，会直接报错并中断，stash 消失，原始修改也没了 - 建议流程：先
Apply，确认没问题再手动git stash drop删除；或者用终端执行git stash pop --index保留暂存状态
stash 列表为空但 git stash list 有内容
VSCode 的 stash 面板（在源代码管理视图底部「STASHES」区域）只显示当前分支对应的 stash，默认不刷新。这不是 bug，是性能取舍——它不会主动轮询 git stash list。
- 使用场景：切换分支后 stash 没自动更新，或别人推送了新 commit 导致本地 stash 基线偏移
- 解决方法：点击 STASHES 区域右上角的刷新图标（↻），或按
Ctrl+Shift+P执行Git: Refresh - 兼容性影响：VSCode 1.85+ 支持
git stash show -p预览，但老版本只能看到描述和时间，看不到具体变更文件 - 注意：
git stash list输出格式依赖 Git 版本，VSCode 解析失败时会跳过该条目，表现为列表比终端少一条
stash 的本质是临时提交，不是备份工具。跨分支操作、rebase 后恢复、或 stash 中含二进制文件时，冲突概率远高于普通 merge —— 这些时候别依赖图形界面的一键操作，终端里看 git stash show -p stash@{0} 更可靠。
