会，git stash pop 容易冲突，因其本质是三方合并，将 stash 中相对于原 head 的变更应用到当前分支 head 上，若文件已被修改或上下文不一致，就会触发冲突。
git stash pop 会冲突吗？
会，而且非常容易。当你在分支 A 上 git stash 了修改，切到分支 B 再 git stash pop，Git 会尝试把暂存区（其实是工作区+暂存区的快照）应用到当前分支的 HEAD 上——如果分支 B 的对应文件已被改动过，或者和 stash 中记录的 base commit 不一致，就会触发合并冲突，哪怕只是同一行被不同分支各自改了一次。
这不是 bug，是设计如此：stash 本质是基于某个 commit 打的补丁，换分支后上下文变了，Git 没法保证无冲突应用。
- stash 记录的是「相对于当前 HEAD 的变更」，不是「相对于某个文件状态」
- 执行
git stash pop时，Git 用git apply --index+git merge-recursive合并，所以行为和git cherry-pick类似 - 如果只想还原暂存区（staged）部分，别用
git stash——它默认同时保存工作区和暂存区
只保存暂存区修改，不碰工作区
用 git stash push -k（-k 即 --keep-index）能保留工作区不变，只把已 git add 的内容存进 stash。这是关键前提：否则你切分支后，未暂存的修改还在工作区漂着，git stash pop 一应用就可能叠加出意料外的状态。
实操建议：
- 确认只 stash 暂存区：
git stash push -k -m "for-branch-x" - 切分支前先
git status看一眼，确保没意外的未暂存修改 - 想单独 stash 暂存区 + 丢弃工作区？用
git stash push -k --discard（Git 2.35+）
跨分支安全应用 stash 的替代方案
直接 git stash pop 风险高，更稳的方式是把 stash 当成一个临时 commit 来 cherry-pick：
- 先查 stash 对应的 commit：
git stash show -p stash@{0} | head -n1（或看git stash list输出里的 hash） - 切到目标分支后，用
git cherry-pick stash@{0}——它走完整 merge 流程，冲突提示更明确，且支持--no-commit先预览 - 如果只是想把暂存区内容“复制”过去（不保留提交历史），用
git stash show -p stash@{0} | git apply --index，它跳过 commit 关联，纯补丁应用
注意：git apply --index 不会自动 git add，但会还原 staging 状态；而 git stash pop 会直接写入暂存区和工作区。
为什么 git stash branch 不总靠谱
git stash branch <name></name> 看似方便，但它创建新分支后直接 git stash pop，依然逃不开前面说的冲突问题。而且它强制基于 stash 的 base commit 创建分支，无法指定目标分支起点——比如你想把暂存区修改应用到 main 的最新版，而不是当初 stash 时的那个旧 commit。
真正需要的是「定向投送」，不是「分支快照」：
- stash 本身没有分支绑定信息，
git stash branch只是语法糖，底层仍是git checkout -b+git stash pop - 如果目标分支有新提交，优先用
git stash show -p | git apply --index，再手动git add和git commit - 别依赖
git stash做长期跨分支同步——它不是 patch 管理工具，更适合短时上下文切换
最易被忽略的一点：stash 列表是全局的，stash@{0} 在不同分支下指向同一个 stash，但应用结果取决于当前分支的文件状态和历史，不是 stash 本身“变”了。
