VSCode仅高亮满足两个条件的冲突文件：git status显示为Unmerged paths，且文件含标准冲突标记（<<<<<<< HEAD、=======、>>>>>>> branch-name）。
Git 合并时出现 conflict，VSCode 会自动高亮哪些文件？
VSCode 不会“自动高亮”所有冲突文件，而是依赖 Git 状态响应 —— 当 git merge 或 git pull 触发冲突后，VSCode 的源代码管理（SCM）侧边栏会把状态为 merge conflict 的文件标记为“冲突文件”，并在编辑器顶部显示黄色横条 + “Accept Incoming” / “Accept Current” 按钮。这些文件必须满足两个条件：git status 中显示为 Unmerged paths，且内容里包含标准冲突标记（<<<<<< HEAD、=======、>>>>>> branch-name）。
常见误判点：
- 手动修改了文件但没
git add，VSCode 可能仍显示“已暂存”状态，实际未进入合并流程 - 冲突被部分解决（删了标记但没
git add），VSCode 仍将其列为冲突文件 - 二进制文件（如
.docx、.png）不会插入文本标记，VSCode 无法提供内联按钮，只能靠git status发现
用 VSCode 内置合并编辑器快速解决文本冲突
点击冲突文件 → 编辑器顶部弹出三栏式合并视图（Current Change / Incoming Change / Result），这是 VSCode 1.84+ 默认启用的 merge editor。它比纯文本编辑更安全，但需注意行为边界：
- 必须先确保该文件处于“未暂存”状态（即还没
git add过），否则不会触发合并视图 - 点击
Accept Current是取当前分支（HEAD）版本；Accept Incoming是取被合并分支版本；Accept Both仅在无重叠变更时可用，否则需手动编辑Result栏 - 修改完
Result后，必须点击右上角Apply Merge（不是 Ctrl+S），否则变更不会写入文件 - 如果关闭了合并视图，再打开会丢失中间状态，得重新
git checkout --ours / --theirs恢复起点
/* 示例：合并视图中 Result 栏最终应类似这样（无冲突标记） */
function calculateTotal() {
return items.reduce((sum, item) => sum + item.price, 0);
}
命令行与 VSCode 混用时，为什么 git add 后冲突文件还在 SCM 列表里？
VSCode 的 SCM 面板刷新依赖 Git 事件监听，而 git add 后若未触发重绘（比如后台运行或终端未回显），列表可能滞后。更关键的是：VSCode 只在文件状态变为 staged 时移除“冲突”标签，但如果你只对部分冲突文件执行了 git add，其余未处理的文件仍会留在列表中 —— 它不是按“本次合并”分组，而是按单个文件状态独立判断。
实操建议：
- 执行
git status --porcelain确认哪些文件还带UU（unmerged）标记 - 在 VSCode 终端中运行
git add <file>后，按Ctrl+Shift+P→ 输入Git: Refresh强制同步状态 - 避免在外部终端
git commit，因为 VSCode 提交界面会校验是否还有UU文件，强行提交会失败并报错fatal: cannot do a partial commit...
如何避免下次合并再掉进同一类冲突？
高频冲突往往不是操作问题，而是协作模式问题。VSCode 本身不解决根源，但可配合配置降低概率：
- 启用
"git.autoRepositoryDetection": true，确保多根工作区下每个子目录都被识别为独立仓库，避免跨项目误合并 - 在
.gitattributes中声明文本文件编码和换行符，例如：* text=auto eol=lf，防止因 CRLF/LF 差异触发假冲突 - 对 JSON/YAML 等结构化文件，安装插件如
Shan Khan - JSON Tools，启用格式化 onSave，统一缩进风格（空格 vs tab）能减少 30%+ 行级冲突 - 团队约定：功能分支每天
git rebase origin/main一次，比频繁git merge main更少产生交叉冲突
真正卡住人的，从来不是按钮在哪，而是某次 Accept Incoming 覆盖了刚写的业务逻辑，却没留心 Result 栏里删掉了关键 if 分支 —— 合并编辑器不会替你理解语义。
