git stash pop 先 apply 再 drop，冲突时仅保留 stash 不删除；需手动解决冲突后 git add/commit 或 git stash drop；stash 默认不存未跟踪文件，跨分支应用易错位，应优先用 git stash branch。
stash pop 会自动删掉 stash，但失败时残留得手动清理
执行 git stash pop 本质是先 apply 再 drop。如果合并冲突导致 apply 失败，Git 不会继续 drop，stash 还留在栈里——下次再 pop 还是同一个，容易误以为“没恢复成功”，其实是卡在冲突没处理完。
- 遇到冲突后先用
git status确认哪些文件有冲突，手工解决后git add+git commit（或git stash drop） - 不想自动 drop，改用
git stash apply，它只还原不删除，更可控 - 执行完
pop后记得检查git stash list，避免重复应用同一份 stash
stash apply 后忘记 drop，多个 stash 堆积导致混乱
很多人习惯用 git stash apply 避免误删，但忘了清理，结果 git stash list 里攒了七八条，分不清哪条对应哪次修改。Git 的 stash 栈是 LIFO，但没有时间戳或分支上下文，纯靠描述字符串识别。
- 加描述再 stash：
git stash push -m "feat/login: token refresh fix"，比默认的WIP on main...好定位得多 - 用
git stash list --oneline快速扫一眼，配合git stash show -p stash@{0}查看具体内容 - 确认无误后，用
git stash drop stash@{0}精准删除某一条，别依赖git stash clear一锅端
切换分支前 stash，切回来 pop 时文件状态不对
stash 默认只保存工作区和暂存区的变更（即 git add 过的），不包括未跟踪文件（untracked）和忽略文件（ignored）。如果你改了新文件但没 git add，git stash 后它就消失了——不是 Git 漏了，是它根本没管。
- 要包含未跟踪文件，必须显式加
-u：git stash push -u - 想连忽略文件也一起存（比如本地配置），加
-a：git stash push -a，但注意这可能把不该传的密钥、日志带进去 - 执行
git stash pop后，如果发现新文件没回来，八成是当初没加-u，而不是操作错了
stash 跨分支应用时路径冲突或内容错位
stash 是基于当前 HEAD 的 diff 打的补丁，换到另一个分支 pop，如果两个分支在相同文件、相似位置都有修改，Git 可能“贴歪”——比如把 A 分支改的第 5 行，硬塞进 B 分支第 8 行，造成逻辑错误，但不报冲突。
- 优先用
git stash branch <new-branch>：它会自动基于 stash 创建新分支并 pop，避免跨分支 patch 错位 - 如果必须跨分支，先
git stash show --stat看改了哪些文件，再对比目标分支的近期提交，预判风险点 - 对关键逻辑文件，pop 后别急着继续写，用
git diff对照 stash 前后的实际变化，尤其关注函数体、条件分支块
stash 不是保险箱，它保存的是「相对于某个提交的差异」，而不是「快照」。每次 pop 都是一次 patch 应用，成败取决于上下文是否匹配——这也是为什么刚 stash 完立刻 pop 很稳，隔两天再试就可能出岔子。
