merge-conflicts插件在atom 1.70+上已不可靠，因其依赖过时的同步api且未适配git 2.30+扩展冲突格式，常静默失效、误删代码或报错“cannot read property 'getbuffer'”，推荐改用atom原生手动处理或迁至vs code+gitlens。
merge-conflicts 插件在当前 Atom（1.70+）上已不可靠，不建议配置或依赖它解决 Git 冲突。 它停更多年，API 兼容性断裂，解析冲突标记经常出错，甚至删掉整段合法代码。真要处理冲突，要么用 Atom 原生方式手动操作，要么直接迁移到 VS Code + GitLens。
为什么 merge-conflicts 插件现在装了也大概率失效
这个插件依赖 Atom 旧版同步 TextEditor.getBuffer() 接口，而新 Atom 改用异步 buffer 加载机制；同时它没适配 Git 2.30+ 的扩展冲突格式（比如 块里嵌套子冲突、<code>||||||| / ======= / >>>>>> branch 多段变体）。实测中常见现象包括：
- 打开含冲突的文件后，插件静默不渲染任何按钮
- 点击
Accept Current后，整段函数被清空，而非仅删冲突标记 - 报错
Cannot read property 'getBuffer' of undefined，且无堆栈可查 - 冲突块里少了一行
=======，插件就完全识别失败，不响应快捷键
如果仍想尝试安装，必须满足这四个硬性条件
即使明知不稳定，也要确保底层环境能“勉强喂得动”它：
- .git 文件夹真实存在于你通过
File → Add Project Folder添加的项目根目录下 - 终端进该目录执行
git status必须输出Unmerged paths（不是both modified或空） - Atom 已完整重启过——尤其刚装完
github或git-plus包之后 - 冲突文件已保存（非
Untitled标签页），且三段标记完整：、<code>=======、>>>>>> feature/x
安装命令只认这一种可靠路径：apm install merge-conflicts。图形界面搜索常卡在旧版本缓存里，装完必须重启 Atom 才可能加载。
快捷键和操作逻辑本身就有隐蔽陷阱
插件激活后，光标落在冲突块内，按 Ctrl+Alt+M（Win/Linux）或 Cmd+Option+M（Mac）呼出菜单。但要注意：
- 它只处理光标所在的那一个冲突块，不会扫全文件；多个冲突需逐个点开操作
-
Accept Both不是智能合并，只是把两段拼一起，空行、重复 import、语法断层全得你手动修 - 它删完标记后不会自动执行
git add，漏这步git commit会卡死在 “unmerged paths” - 删完务必检查是否残留孤立的
=======行——Git 把它当新冲突起始，git status会持续报 conflict
真正容易被忽略的是：冲突解决不是“插件点了 Accept 就完事”，而是“删干净标记 + 保留逻辑正确 + 手动 git add 确认”。Atom 不管后两者，而 merge-conflicts 连第一项都经常翻车。现在还硬扛着用它，不如花半小时迁到 VS Code，GitLens 对冲突的识别、对比、写入、add 是端到端闭环，且支持 Accept Both Changes 的语义去重——这才是现代协作该有的底线。
