快捷键alt+f、alt+i、alt+b可快速接受当前、传入或双方更改，需光标位于冲突块内（如>间），否则无效；误用ctrl+j会破坏冲突标记及语法，不可用于冲突块。
冲突文件里怎么快速选中并接受某一方更改
VSCode 冲突块上方默认显示三个按钮：“Accept Current Change”、“Accept Incoming Change”、“Accept Both Changes”。但手动点太慢，尤其多处冲突时。真正高效的是快捷键：Alt+F（当前分支）、Alt+I（传入分支）、Alt+B（双方）。这些键只在光标落在冲突块内时生效，且不依赖鼠标焦点——哪怕你刚从终端切回来，只要光标在和<code>>>>>>> commit-hash之间，就能直接触发。
常见错误是光标停在冲突标记行外（比如空行或注释行），此时快捷键无反应；也有人误按Ctrl+Z撤销，结果把刚选的更改回退了——VSCode 不会自动暂存冲突解决结果，撤销后得重来。
- 必须确保光标位于冲突块内部，哪怕只在
=======那一行也行 -
Alt+B会保留双方内容，但不会自动加换行或分号，console.log(a)和console.log(b)合并后变成console.log(a) console.log(b)，需手动补分号 - 如果快捷键失效，先检查是否启用了
"git.mergeEditor": true——旧版合并编辑器下快捷键可能被禁用
合并前用什么命令预览差异最靠谱
别等 git merge 报错才打开 VSCode。提前用 Git: Compare Branches（Ctrl+Shift+P 输入执行）看真实差异。它比 git diff branch-a..branch-b 更直观：左侧是当前分支，右侧是目标分支，增删改用颜色区分，还能逐行点击“Accept”或“Reject”，相当于预演合并。
这个操作不修改任何东西，但能暴露两类典型风险：一是两个分支都改了同一函数的参数列表，但改法互斥；二是某人重命名了文件，另一人还在原路径 import ——这类路径冲突在纯文本 diff 里不明显，但在 VSCode 双栏对比中，文件名变红+路径断开，一眼就能揪出来。
- 对比前先
git fetch，否则看到的可能是过期的远程分支状态 - 如果目标分支名含斜杠（如
feature/login-ui），输入时别漏掉斜杠，否则命令面板可能匹配不到 - 对比窗口右上角有“Compare Against”下拉菜单，可切换为比较特定提交，适合排查某次 PR 引入的问题
为什么 Ctrl+J 不能用来合并 Git 冲突
Ctrl+J 是「合并代码行」，不是「解决 Git 冲突」。它干的事很简单：删掉选中区域里的所有换行符，换成空格。对冲突块执行它，、<code>=======、>>>>>> commit-hash 全被压成一行，后续所有 VSCode 冲突识别逻辑全部失效——编辑器再也认不出这是冲突，也就不会再显示那三个 Accept 按钮。
更糟的是，它还会破坏语法结构。比如你选中两行对象属性：a: 1, 和 b: 2,，按 Ctrl+J 后变成 a: 1, b: 2,，看着没问题，但若其中一行末尾没逗号，或某行有注释，结果就是 a: 1,//comment b: 2,，直接导致语法错误。
- 冲突块里永远不要用
Ctrl+J，哪怕只是想“整理一下格式” - 如果误用了，立刻
Ctrl+Z撤销；若已保存，用源代码管理面板右键文件 → “Discard Changes” 回退到冲突原始状态 - 真想压缩多行代码，先复制冲突块外的内容做测试，确认无副作用再操作
合并后最容易被忽略的验证动作
点完所有 Accept 按钮、保存文件、执行 git add 和 git commit 后，很多人以为结束了。但 VSCode 不会帮你检查语法是否合法、类型是否匹配、或者是否删掉了本不该删的条件分支。最常漏掉的是：没运行本地测试，也没检查 CI 是否通过。
尤其要注意那些“看起来没改”的文件——比如冲突发生在配置文件或类型定义中，表面只是调整了字段顺序，但下游服务可能强依赖字段位置。VSCode 的差异视图里，这类变更常以绿色+蓝色混合高亮，容易被当成无关紧要的格式调整。
- 合并后第一件事：在终端运行
npm test或对应测试命令，至少跑一遍单元测试 - 如果项目启用了 ESLint 或 TypeScript，保存文件后留意底部状态栏是否有红色波浪线——VSCode 有时不会实时刷新类型错误
- 别跳过
git status，确认所有冲突文件确实已暂存；偶尔会出现“部分冲突已解决但未add”的情况，提交后依然报 conflict
