VS Code内置Git集成已足够解决绝大多数冲突，真正起作用的是对上下文的理解和手动决策；Accept Both Changes仅机械拼接代码、不做语义判断，易致重复import、变量覆盖或语法错误，仅适用于日志拼接等极少数场景。
VS Code 自带的 Git 集成已足够解决绝大多数冲突，所谓“智能合并插件”基本是营销话术——真正起作用的是你对冲突上下文的理解和手动决策，不是按钮。
为什么 Accept Both Changes 经常翻车
这个按钮只是机械拼接两段代码，不做任何语义判断。常见问题包括：
-
import语句重复：两边都加了import axios from 'axios'，点完直接报错“Duplicate import” - 同名变量赋值覆盖：左边写
config.timeout = 5000，右边也写config.timeout = 10000，中间区出现两行，后者生效但前者意图丢失 - 函数体结构冲突：一个分支改了
if (x) { ... }的条件，另一个删了整个块，Accept Both Changes会把if和后续裸代码并排堆在一起，语法直接崩
它适合的场景极少，比如日志字符串拼接、纯配置项追加（且确认无键名重复）。其他情况请默认忽略这个按钮。
三栏合并编辑器必须开，且要手动调出
VS Code 默认的内联按钮（Accept Current Change 等）只在光标进入冲突块时才浮现在顶部，键盘党或快速跳转时极易错过。更可靠的方式是强制启用三栏视图：
- 打开冲突文件后，按
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS） - 输入
Merge Editor: Open Merge Editor并回车 - 确保设置中
git.mergeEditor为true，否则该命令不可用 - 若仍失败，检查文件编码是否为
UTF-8；含GBK中文注释的文件会导致合并编辑器拒绝加载
三栏（左=当前分支 / 右=传入分支 / 中=编辑区）能清晰暴露差异边界，避免误点“接受当前”却删掉关键逻辑。
冲突解决完不 git add 就等于没解决
这是批量处理时最常漏掉的一步：
- 用
Git: Accept All Current Changes一键处理整个文件后，VS Code 只改了内容，文件状态仍是MERGE_CONFLICT - 必须手动在源代码管理视图中点击该文件旁的
+号，或终端执行git add <file></file> - 多个文件全部处理完后，还要点一次
Commit Merge按钮（或git commit），否则 Git 认为合并未完成，远程推送会失败
VS Code 不会替你执行 git add，它只负责编辑器层面的文本操作。这一步卡住，就永远停在“冲突未解决”状态。
真正需要关注的不是插件，而是合并前的准备动作
90% 的冲突痛苦源于合并前没做这几件事：
- 切换到目标分支后，先运行
git fetch，否则 VS Code 分支列表可能滞后，选不到最新feature分支 - 确保状态栏显示的是你要合并进来的分支（如
main），再右键源分支选Merge from；在feature分支上点Merge from main是无效操作 - 有未提交修改时，VS Code 会阻止切换分支，此时别硬切，先
git stash或提交再操作 - 启用
git.autofetch设置，让 VS Code 后台自动同步远程状态，减少手动fetch频次
所谓“智能”，不在工具，而在你是否让 Git 知道足够多的上下文——共同祖先、最新远端快照、干净的工作区。这些才是三路合并能少出错的前提。
