“Accept Both Changes”不是智能合并，只是机械拼接Current和Incoming代码，不校验语义，易致重复import、函数重定义、变量赋值覆盖等错误，必须手动清除冲突标记并逐行验证逻辑一致性。
为什么“Accept Both Changes”点了就出错
这个按钮不是智能合并，只是把 Current 和 Incoming 两段代码上下拼接，不判断语义是否冲突。Accept Both Changes 常见报错包括重复导入、重复定义函数、字段赋值覆盖丢失意图。比如两边都写了 config.timeout = 5000 和 config.timeout = 10000，结果会保留两行，后一行覆盖前一行，但你根本不知道哪一行该留。
- 它不会删掉
<<<<<< HEAD、=======、>>>>>> branch-name这三行标记，必须手动清空 - 如果两段代码修改了同一个对象的同一属性，拼接后大概率运行时报错或逻辑错乱
- 适合用在完全不重叠的区域，比如一个加了日志，一个改了返回值，中间没交集
光标不在冲突块里，按钮就不亮
VSCode 的合并按钮（Accept Current Change、Accept Incoming Change）只在光标落在标准冲突标记块内时才激活。常见失效场景不是插件问题，而是状态没对上。
- 先确认
git status输出含both modified: path/to/file，不是modified: - 必须从 SCM 面板点击文件名打开，双击文件标签页不会进三栏合并视图
- 底部状态栏没出现浅灰色操作条，说明当前没识别到有效冲突块
- 搜一下
<<<<<< HEAD，缺任意一行（比如漏了=======）都会导致按钮灰掉
手动编辑 Result 栏前必须删干净三行标记
中间可编辑区（MERGED）支持自由输入，但只要残留任意一行冲突标记，git add 就会失败，报 fatal: cannot lock ref。
- 不能只删
<<<<<< HEAD和>>>>>> branch-name，=======必须一起删 - 删完后检查：整个冲突块应只剩你手动整理后的合法代码，无任何
<或>开头的标记行 - 保存（
Ctrl+S）只是写入磁盘，不等于 Git 认为已解决；必须右键文件 →Stage Changes或执行git add <file>
想看 BASE 版本？别点“Compare with…”，要用 Git: Open Merge Editor
普通文件对比（File: Compare Active File With）只比两个快照，看不到共同祖先（$BASE）。真正需要理解变更来源时，得强制调出四窗格模式。
- 快捷键
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（Mac），输入并选Git: Open Merge Editor - 界面分四区：左上
CURRENT（你的）、右上INCOMING（对方）、左下BASE（原始）、右下MERGED（可编辑） - 每个差异块右侧有小图标：
→插入 CURRENT，←插入 INCOMING，↑↓可切换聚焦区域 - 改完必须关掉整个合并编辑器窗口（不是只关标签页），否则 Git 流程卡住
