git stash 默认只保存已跟踪文件的修改和暂存区状态，不包含未跟踪文件（如新建的.env.local），需显式加-u参数；VSCode“Stash Changes”自动适配暂存状态，无弹窗即执行了stash push -m；pop失败时stash仍保留，需手动apply后drop清理。
git stash 不是“一键保存所有改动”的万能快照，它默认只管已跟踪文件的修改和暂存区状态，新文件、忽略文件、未 git add 的改动全都不收——用错参数或没看清状态，stash 后发现“代码丢了”，其实是压根没存进去。
git stash 默认不存新建文件，必须加 -u
你新建了 .env.local，改了几行，没运行过 git add，然后执行 git stash。结果切分支回来一查，文件还在工作区？不，它根本没被 stash 收走——因为它是 untracked 文件，默认被跳过。
-
git stash和git stash push默认行为一致：只处理 tracked 文件的 staged + unstaged 变更 - 要包含所有未跟踪文件（比如本地配置、日志、临时生成文件），必须显式加
-u：git stash push -u - 加了
-u后，git status里显示为Untracked files:的条目才会进 stash；否则它们留在原地，且恢复时也不会动它们 - 注意：如果该文件在
.gitignore里，-u也不管——得再加-a，但慎用，可能把密钥、token 一起塞进 stash
VSCode 的 “Stash Changes” 没弹窗，其实已经执行了
你右键一个已修改文件 → 点 “Stash Changes”，结果啥也没弹出来，工作区看起来“没变化”。这不是卡死，是 VSCode 根据当前暂存区状态做了自动判断。
- 如果当前 没有任何
git add过的变更（即全是 unstaged 修改），VSCode 直接执行git stash push -m "VS Code stash"，不弹窗 - 只要存在至少一个 staged 文件（哪怕只有一个
git add README.md），VSCode 就会弹窗，让你选：“Stash including staged changes” 还是 “Stash only untracked and modified” - 弹窗容易被遮挡（尤其多窗口/分屏时），留意右下角状态栏是否出现 “Stashing changes…” 提示；没看到就切终端看有没有阻塞进程
- VSCode 不支持
git stash push -S（仅 stash staged 部分）这类精细控制，想这么干，必须切终端
git stash pop 失败后 stash 还在，不是 Git 漏删
执行 git stash pop 报冲突，你关掉终端去修代码，回头再试，发现 git stash list 还有那条记录——不是 Git 漏删，是它根本没删。
-
git stash pop本质是git stash apply+git stash drop两步；apply失败时，drop不会执行 - 所以冲突后
git stash list仍能看到stash@{0}，下次pop还是它，容易反复撞同一处冲突 - 解决办法：先
git stash apply，手动解决冲突并git add，再git stash drop显式清理 - 别依赖
pop自动清理，尤其在多人协作或复杂合并场景下
最容易被忽略的是：stash 是纯本地操作，不跨 clone，不进远程，也不进 IDE 缓存；一旦误清或机器重装，stash 就真没了。关键进度建议配合 git commit -m "WIP: xxx" + git reset HEAD~1 做双重保险。
