git status 不显示行号，因其仅报告文件状态（如unmerged paths），不解析代码语义；冲突具体位置需通过文件内
git status 为什么只显示文件名，不标行号
因为 Git 本身不解析代码语义，git status 只负责报告哪些文件处于 Unmerged paths 状态，它不管你在第几行改了什么。真正标记冲突位置的是 Git 在文件里插入的三段式分隔符，不是命令输出。
运行 git status 后，你会看到类似这样的输出：
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: src/api/client.js
both modified: package.json</file>
这说明冲突确实存在，但具体在哪一行？得打开文件自己找。
- 所有冲突块都以
开头，以 <code>>>>>>> [commit-hash]结尾 到 <code>=======是你本地（当前分支）的改动-
=======到>>>>>>是要合并进来的改动（比如origin/main） - 一个文件可能有多个冲突块，别只修第一个就以为全搞定了
用 VS Code 快速跳转所有冲突位置
VS Code 内置了冲突导航能力，但默认不自动展开全部，容易漏掉隐藏冲突。
正确做法是：
- 打开冲突文件后，按
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（Mac） - 输入
Merge Conflict: Show Conflicts并回车 - 它会弹出侧边面板，列出所有冲突块的位置（如
line 42、line 187） - 点击任一位置，编辑器直接跳转并高亮该区块
如果你启用了 "git.mergeEditor": true 设置，还可以在源代码管理视图中点开「Merge Editor」，左右对比 BASE / CURRENT / INCOMING，比纯文本更防手滑。
命令行下怎么快速定位冲突行号
不想开编辑器？可以用 grep 直接搜标记行：
grep -n ">>>>>" src/api/client.js
输出类似：
42:>>>>> a1b2c3d
这样一眼看出冲突发生在第 42–46 行。注意：grep 不会帮你判断逻辑对错，只是把 Git 插入的标记“揪出来”。
- 如果文件里有大量注释含
或 <code>>>>（比如文档里的 ASCII 图），加-F参数避免误匹配：grep -Fn " - 想批量查所有冲突文件？先
git status --porcelain | grep "^UU" | cut -d' ' -f2-拿到路径，再循环grep
二进制文件冲突根本没法看行号，怎么办
PDF、图片、.docx 这类文件 Git 不生成文本标记，git status 显示 both added 或 added by us，但不会告诉你哪里“不一样”——因为 Git 压根读不懂内容。
这时候定位靠的是元信息和外部工具：
- 用
git ls-files -s <path></path>查看两个版本的 blob hash，不同就代表内容真变了 - 用
file <path></path>确认文件类型是否一致（比如从 PNG 被另存成 JPEG 就算“冲突”） - 用
pdfinfo <path></path>（需安装 poppler）对比 PDF 元数据：生成软件、修改时间、页数等 - 对图像，可用
identify -verbose <path></path>（ImageMagick）看尺寸、颜色空间、压缩方式
二进制冲突的本质不是“哪行错了”，而是“要不要换新文件”。所以定位重点从来不是行号，而是确认：这个新版本是不是设计/产品/法务认可的终稿。
