git stash 后 git checkout 仍报错，是因为默认不暂存未跟踪文件（untracked files），需加 -u 参数；命名建议用 git stash push -m 显式标注功能，避免混淆；apply 仅应用不删除，冲突需手动解决，推荐先 apply 再 drop。
stash 之后为什么 git checkout 还报错？
因为 git stash 默认只暂存「已跟踪但未提交」的修改，不包括新创建的未跟踪文件（untracked files）。如果你刚新建了 config.local.js 或日志文件，git status 显示它们是 untracked，那 git stash 后切换分支仍会失败——Git 拒绝覆盖工作区里这些新增文件。
解决办法是加 -u 参数：
git stash -u
它会把未跟踪文件也一并藏起来。如果还包含忽略文件（比如 .DS_Store），得用 -a（--all）。
-
-u：暂存已跟踪修改 + 未跟踪文件 -
-a：再额外包含被.gitignore忽略的文件 - 执行前建议先
git status确认当前有哪些变更类型
stash 的名字怎么起才不容易混淆？
默认 stash 名字是 WIP on main: abc1234 fix login timeout，但多人协作或频繁 stash 时，光看哈希和分支名根本分不清哪个是「修复支付回调」那个、哪个是「临时改样式调试用的」。
用 git stash push -m 显式命名：
git stash push -m "feat/pay: add wechat callback timeout retry"
这样后续用 git stash list 就能一眼识别，也方便用 git stash apply stash^{/wechat} 模糊匹配恢复。
- 消息里建议带上模块/功能前缀（如
fix/api、chore/test） - 避免用
temp、test、xxx这类无意义词 - 别依赖自动消息——
git stash不带-m时不会读你最近 commit 的 message
apply 之后为什么文件没变，或者冲突一堆？
git stash apply 是“应用”而非“弹出”，stash 列表还在，且它只是把差异 patch 打到当前工作区，不做任何合并逻辑。如果当前分支已有同位置修改，就会直接冲突；如果 stash 里删了某行，而当前分支新加了同一行，apply 也会失败。
更安全的做法：
- 先
git stash apply stash@{0}（指定序号，避免误操作） - 检查结果，没问题再
git stash drop stash@{0} - 如果冲突，用
git status查看哪些文件冲突，手动解决后git add即可，不用git commit - 想一次性恢复并删除，用
git stash pop，但它失败时不会自动回滚，仍需手动git stash drop
紧急切分支后发现 stash 内容不对怎么办？
常见情况：在 dev 分支 stash 了一堆改动，切到 hotfix/login 后 git stash apply，结果发现里面混着昨天写的数据库迁移脚本——那是你在另一个分支上忘清的旧 stash。
stash 是全局栈，按时间倒序排列：stash@{0} 是最新，stash@{1} 是上一个……所以关键不是“我在哪分支 stash 的”，而是“我 stash 的顺序”。
- 用
git stash list配合-p看具体内容：git stash show -p stash@{1} - 误 apply 后想撤回？只要没 commit，
git reset --hard能清掉 apply 带来的变更（慎用） - 长期 stash 容易失效：如果 base commit 被 rebase 或 cherry-pick 过，apply 可能失败或行为异常
真正紧急时，stash 是快刀，但别把它当保险柜——超过 2 天没用的 stash，建议要么恢复提交，要么 git stash drop 掉。
