goland 虽能自动合并 go.mod/go.sum 文本，但语义冲突常致 ci 构建失败；因 git 仅做行级合并，而 go 在构建时才通过 mvs 重算依赖树，易引入未测试组合或 checksum mismatch。
GoLand 能自动处理大部分 Git 文本合并，但多分支开发中真正麻烦的不是“文件行冲突”，而是 go.mod 和 go.sum 的语义性冲突——它们看起来没红标、能自动合并，却在 CI 构建时突然报错。
为什么 go.mod 合并后不报错，但构建失败？
Git 会把两个分支的 go.mod 按文本合并，比如 A 分支加了 require github.com/pkg/v2 v2.1.0，B 分支删了它，合并后可能保留两行、或只剩一行但版本不对。Go 不校验“写法是否合理”，而是在 go build 或 go mod tidy 时触发 MVS（最小版本选择）重新计算整个依赖树——结果可能选了一个没人测试过的组合。
-
go.sum中残留多个校验和条目（如同一模块出现v1.5.0和v2.1.0两行），go build直接抛checksum mismatch - 分支用了
replace指向本地路径，合入主干后 CI 找不到该路径，报cannot find module -
go list -m all在 A 分支输出 12 个模块，在 B 分支输出 14 个，合并后变成 16 个——说明依赖图已不可控
GoLand 内解决 go.mod 冲突的实操要点
别只盯着“冲突对话框里点 Accept Theirs”——那只会让 go.mod 变成另一分支的快照，而不是你想要的可构建状态。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 先关闭“自动应用无冲突更改”按钮（工具栏上那个
Apply All Non-Conflicting Changes），否则go.mod里看似无关的// indirect行会被悄悄覆盖 - 在中央窗格手动删掉重复的
require行，保留语义清晰的一条；对replace行，检查注释（如// replace for branch-x: fix race, remove before merge），确认是否该保留 - 右键点击冲突行，用
Resolve using Left或Resolve using Right快速取舍，但之后必须立刻验证：在终端执行go mod tidy -v，观察是否有downloading或removing输出 - 如果发现
go.sum有冲突标记（>>），不要直接删中间块——先删掉整个go.sum，再跑一次go mod tidy，比手动修更可靠
合并前必须在 GoLand 里验证的三件事
点 Merge 按钮前，打开 Terminal 标签页，逐条执行：
-
go mod tidy -v—— 看输出里有没有新下载包；如果有，说明依赖树变了，得查清是哪行require引起的 -
go list -m all | grep "your-critical-dep"（例如database/sql或golang.org/x/net）——核对关键依赖版本是否与设计文档一致，尤其注意/v2这类主版本后缀是否缺失 -
git status—— 确认go.sum已加入暂存区；如果它显示 “modified”，说明刚生成的校验和没提交，CI 会失败
最常被忽略的是：GoLand 的“解决冲突”窗口只管文本，不管语义。哪怕所有文件都绿了、冲突图标消失了，go.mod 里一行多余的 // indirect 或一个没删干净的 replace 都可能让下游服务启动失败。验证动作不能省，也不能只靠 IDE 提示。
