git stash 不是代码热备份，而是临时腾出工作区的机制；它不记录时间戳、不校验完整性、不保存未跟踪文件、不跨仓库同步，冲突恢复时易导致修改丢失。
VSCode 里没有“代码热备份”这个功能，git stash 是最接近的替代方案——但它不是备份，而是临时移除当前修改、让工作区变干净；误操作或冲突处理不当，反而会导致修改丢失。
为什么不能把 git stash 当成“热备份”用
stash 的设计目标是「临时腾出工作区」，不是「安全存档」。它不记录时间戳、不校验内容完整性、不跨仓库同步，更不会自动清理过期条目。你执行 git stash pop 时如果发生冲突，VSCode 默认只标 CONFLICT，不会暂停或提示你先备份；一旦你手快点了 Stage 或 Commit，原始修改就彻底覆盖了。
- stash 记录存在本地 Git 对象库中，重装系统、删掉 .git 目录、clone 新副本时全部消失
- stash 不保存未跟踪文件（
untracked），比如刚建的.env或config.local.json，除非手动加-u参数 - VSCode 的
Git: Show Stash List只显示最近几条，git stash list才能看到全量；UI 不展示每条 stash 具体改了哪些文件
想“临时保存修改”，必须分清 staged 和 unstaged 状态
VSCode 的源代码管理面板把文件分成两块：「更改」（unstaged）和「已暂存的更改」（staged）。stash 会一并收走这两部分，但行为受 Git 配置影响：
Git Pushing
下载
使用约定式提交信息暂存、提交和推送git更改。当用户想要提交和推送更改、提到推送到远程、或要求保存并推送工作时触发。也适用于用户说“推送更改”、“提交并推送”、“推送这个”、“推送到github”或类似git工作流程请求时。
- 默认只 stash 已跟踪 + 已修改/已暂存的文件；新文件（untracked）被忽略
- 想包含新文件，终端运行：
git stash push -u -m "wip: api retry"（-u=--include-untracked） - 只想 stash 已暂存部分（保留 unstaged 修改继续调试），终端运行：
git stash push -S（-S=--staged） - VSCode 命令面板里的
Git: Stash不支持-S或-u，必须切终端
stash 后文件还在“更改”列表？先查这三件事
这不是 VSCode bug，是 Git 行为边界没对齐导致的错觉：
- 文件在
.gitignore里（如node_modules/、dist/），Git 根本不管理它，stash 自然无效 - 文件是新建的、从未
git add过，属于 untracked 状态；stash 默认跳过，需-u - UI 缓存延迟：按
Ctrl+R（Windows/Linux）或Cmd+R（macOS）强制刷新源代码管理面板
真正安全的“临时保存”，得靠组合动作
单靠 stash 不足以防丢，建议固定流程：
- 修改前先确认状态：
git status看清楚哪些是 tracked、哪些是 untracked、哪些已 stage - stash 前加描述：
git stash push -m "wip: user auth flow, pending token refresh"，避免日后看不懂自己存了啥 - 恢复前先预览：
git stash show -p stash@{0}，确认是不是你要的那批修改 - pop 冲突后别急着 commit：先右键冲突文件 →
Stage Changes，再检查是否所有改动都已纳入暂存区
最易被忽略的一点：stash 列表不会自动更新，Git: Show Stash List 只在你主动触发时拉取一次；中间你用终端执行了 git stash drop 或 git stash clear，VSCode UI 完全不知情，仍显示旧列表。
