应先用git status确认both modified文件，再用grep -n ""搜索行号定位冲突标记，或在vs code中直接搜索“
怎么快速定位冲突标记行
冲突标记（、<code>=======、>>>>>> feature/login）不是语法错误，但会被 Git 当作普通文本保留，所以不能靠编译或 lint 报错发现。最直接有效的方式是用 git status 确认哪些文件处于 both modified 状态，再对这些文件做文本搜索。
推荐在终端中执行：
grep -n ">>>>>" file1.java file2.py config.yml
注意： 和 <code>>>>>>> 是特殊字符，需用反斜杠转义；grep -n 会显示行号，方便编辑器跳转。
如果你用 VS Code，可直接在搜索框输入 并勾选“匹配整个单词”和“区分大小写”，它会高亮所有冲突区块——比全局 grep 更快，尤其适合只改了少量文件时。
为什么 git status 显示的文件不一定都有冲突标记
Git 把“未合并路径”当作冲突状态，但某些情况会导致误报：比如文件权限变更、行尾换行符不一致（CRLF vs LF）、或者某次 git add 后又手动改了文件但没重新 add。这时 git status 仍显示 both modified，但打开文件看不到冲突标记。
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
- 先运行
git checkout --ours <file></file>或git checkout --theirs <file></file>恢复单个文件到某一方版本，再git status看是否还报冲突 - 若恢复后状态消失，说明原文件只是暂存区与工作区不一致，而非真实内容冲突
- 若仍存在，再检查是否漏删了冲突标记（比如只删了
和 <code>=======，但忘了删>>>>>>）
git diff 能看出冲突位置吗
不能直接看。默认 git diff 只对比工作区与暂存区，而冲突发生时，暂存区里存的是“冲突前的状态”，工作区里是带标记的混合内容，所以 git diff 输出往往为空或只有无关改动。
真正有用的是：
-
git diff --base <file></file>：对比工作区与冲突前共同祖先（即 merge 前的 HEAD） -
git diff --ours <file></file>：对比工作区与当前分支版本 -
git diff --theirs <file></file>：对比工作区与待合并分支版本
这三个命令能帮你确认哪边改了什么，避免盲目删掉某一段代码后才发现逻辑断掉了。
编辑器自动识别失败的常见原因
VS Code、WebStorm 等现代编辑器通常能自动识别并渲染冲突区块，但以下情况会让它们失效：
- 冲突标记被拆成多行（比如
后面跟了空格或注释） - 文件编码不是 UTF-8（如 GBK 编码下
=======可能被截断） - 使用了自定义的 .gitattributes 设置了
merge=ours或merge=theirs，导致 Git 跳过了标准冲突标记插入
遇到识别失败，别依赖 UI 按钮，老老实实用 grep 或文本搜索找三段标记——这是唯一不依赖环境、100% 可靠的方式。
