vscode的git冲突diff视图需满足三前提：git status显示conflicted文件、该文件已打开且被git追踪；冲突块以> branch-name标记，行号旁有红/绿侧边栏并提供“accept”按钮；按钮按git标记的ours/theirs分组，但逻辑归属需结合合并方向（如feature merge main时ours实为feature代码）判断，悬停可查看具体来源，语义变更须人工比对上下文。
VSCode怎么打开Git冲突的Diff视图
VSCode内置的合并冲突处理，不是靠手动打开某个菜单触发的，而是Git在产生冲突后自动标记文件状态，VSCode顺势渲染出可交互的Diff界面。关键前提是：git status 能看到 conflicted 文件（比如显示 both modified），且该文件已打开在编辑器中。
常见错误现象：点了右上角“Merge Changes”按钮没反应，或根本看不到冲突高亮——大概率是文件没保存、没被Git追踪，或当前分支没真正发生冲突（比如只是本地修改未 git pull）。
- 确保执行过
git pull或git merge后出现冲突提示，且没用git merge --abort回退 - 在VSCode中打开那个被标为“冲突”的文件（资源管理器里会显示黄色感叹号图标）
- 冲突块会以
/ <code>=======/>>>>>> branch-name形式原样存在，VSCode会在行号旁加红/绿侧边栏，并提供“Accept Current Change”“Accept Incoming Change”等操作按钮
怎么用VSCode的“Accept”按钮安全选代码
VSCode不会替你判断哪段逻辑该留，它只按Git标记的“ours”（HEAD，即当前分支）和“theirs”（incoming，即要合并进来的分支）来分组。但实际开发中，“ours”未必就是“主干”，尤其当你在 feature 分支上 git merge main 时，“ours”反而是 feature 分支的代码。
容易踩的坑：盲目点“Accept Current Change”，结果把还没测试的新逻辑覆盖掉了线上稳定的旧逻辑。
- 先看顶部状态栏：VSCode会显示类似
Merging feature/login into main的提示，确认方向是否符合预期 - 鼠标悬停在每个冲突块的“Accept”按钮上，会提示具体来源（例如 “Accept from main” 或 “Accept from feature/login”）
- 如果冲突涉及函数签名变更、API调用替换等语义级改动，别只看按钮文字，得手动比对上下文——按钮只管文本块，不管业务逻辑
为什么有时候VSCode不显示冲突按钮，只看到原始
这是VSCode没识别到Git工作区状态，最常见于三种情况：Git插件被禁用、工作区根目录不是Git仓库顶层、或VSCode启动时Git尚未就绪。
性能影响不大，但会彻底阻断可视化操作，被迫退回命令行。
- 检查左下角状态栏有没有
main（或分支名）和 Git 图标；没有的话，点击那里 → “Initialize Repository” 或 “Open Repository” - 确认VSCode打开的是Git仓库的根目录（
.git文件夹所在路径），而不是子文件夹——否则git.statusAPI 拿不到正确信息 - 重启VSCode后仍不显示，试试在命令面板（
Ctrl+Shift+P）运行Git: Refresh Source Control
合并后怎么验证没漏改、没多删
VSCode的“Accept”操作只是编辑文本，不校验语法、不跑测试、不检查 import 是否断裂。一次手滑可能让整个模块编译失败。
最容易被忽略的是：冲突解决后，VSCode不会自动帮你 git add，也不会提醒你还有未暂存的修改。
- 解决完所有冲突块后，务必看左下角源代码管理面板——冲突文件应从“MERGE CHANGES”区域消失，进入“CHANGES”列表
- 此时必须手动右键文件 → “Stage Changes”，或点击文件旁的
+号，否则git commit会失败并报错error: cannot lock ref 'HEAD': is at ... but expected ... - 提交前，至少快速扫一眼修改预览（点击文件名旁的“…” → “Compare with HEAD”），重点看 import 行、闭合括号、缩进层级有没有异常变动
