git stash 失败的根本原因是工作区“不干净”，Git 拒绝覆盖未提交修改；需用 git status 确认修改状态，按需选用 git stash（仅已跟踪文件）、-u（含未跟踪文件）或 -a（含忽略文件），避免丢失新增文件；pop 会删除记录且默认操作栈顶，易致恢复失败，推荐先 apply 再手动 drop；跨分支应用 stash 存在隐性冲突风险，应优先使用 git stash branch 创建新分支恢复；长期 stash 缺乏版本管理、易丢失、难追溯，超 3 天未用建议清理或转为草稿提交。
切换分支前 git stash 为什么经常失败
根本原因不是命令写错了，而是工作区“不干净”——Git 拒绝覆盖你未提交的修改。报错典型如 Your local changes would be overwritten by checkout，这时直接 git checkout -f 强制切换会丢弃改动，风险极高。
正确做法是先确认哪些文件被修改：git status 看输出；再决定是否要暂存未跟踪文件（比如新写的组件、配置）：
-
git stash：只暂存已跟踪文件（即之前 commit 过的），新增文件（untracked）会被忽略 -
git stash -u：包含未跟踪文件（但不包括 .gitignore 里声明的） -
git stash -a：连node_modules、.log这类忽略文件也暂存（慎用，体积大且易污染）
切记：如果 git status 显示有 untracked 文件却只用 git stash，切过去再 git stash pop 时，那些新文件就找不回来了。
git stash pop 和 git stash apply 的关键区别
git stash pop 是“取出来 + 删掉记录”，而 git stash apply 是“取出来但保留 stash 记录”。多数人默认用 pop，但容易踩两个坑：
- 恢复后发生冲突，pop 已执行、stash 已删，想重试都找不到原始状态了
- 多个 stash 并存时，
git stash pop总是操作stash@{0}（栈顶），但你可能想恢复的是stash@{2}
建议流程：先 git stash list 确认目标索引 → 用 git stash apply stash@{2} 尝试恢复 → 检查是否冲突/是否符合预期 → 再手动 git stash drop stash@{2} 删除
跨分支应用 stash 的隐性冲突风险
在 A 分支 git stash 后切到 B 分支 git stash apply，表面可行，但实际非常危险：
- B 分支可能没有 A 分支里被修改的文件（比如 A 新增了
utils/date.ts，B 分支还没这个文件），apply 会失败或静默跳过 - 即使文件存在，B 分支该文件的 base 版本和 A 分支不同，apply 时产生的冲突内容，和你在 A 分支看到的 diff 完全不是一回事
- Git 不校验 stash 来源分支，它只管把 patch 打上去，不管语义是否合理
更稳妥的做法是：git stash branch new-feature-from-stash —— 它会自动从 stash 创建新分支，并把 stash 应用上去，避免污染当前分支，也方便后续 rebase 或 cherry-pick。
长期 stash 的管理成本比想象中高
很多人习惯 git stash save "临时改一下" 留着不用，等哪天想起来再恢复。但 stash 栈不是待办清单，它是无版本控制的临时空间：
- stash 记录不带作者、不带时间戳（只有相对序号），
stash@{5}到底是谁、什么时候、为什么存的？全靠手写 message，而多数人不写或写得模糊 - 每次
git pull、git merge、甚至git stash自身都会改变 stash 索引顺序，stash@{0}下一秒可能就变成stash@{1} - stash 内容不会随
git push同步到远程，换机器或重装环境后全部丢失
超过 3 天没用的 stash，建议要么 git stash show -p stash@{0} 看一眼内容决定是否转成草稿 commit，要么直接 git stash drop stash@{0} 清掉——留着只会增加认知负担，而不是安全感。
