git冲突未弹窗因操作非ide触发，需手动调用resolve conflicts；三窗格工具不识别语义冲突，必须本地构建+测试验证逻辑正确性。
Git冲突弹窗没出现，但git status显示unmerged
GoLand 检测到冲突时默认会弹出图形化冲突对话框，但这个行为依赖两个前提：操作由 IDE 触发（比如点击 Merge 按钮），且未被手动关闭或跳过。如果你是在终端执行了 git merge 或 git pull 后再切回 GoLand，IDE 不会自动感知——它只会在你主动右键文件选 VCS | Git | Resolve conflicts，或在 Local Changes 工具窗口里点击 “Resolve” 链接时才启动解决流程。
此时 git status 仍显示 both modified，文件里也还留着 这类标记，但 GoLand 编辑器里可能只是普通高亮，没有三窗格界面。别硬改标记行，先手动唤起解决工具：
- 打开
Local Changes工具窗口（Alt+9），找到标红的冲突文件，点右侧的Resolve - 或直接在编辑器里右键冲突文件 →
VCS | Git | Resolve conflicts - 若上述入口灰掉，说明 GoLand 认为当前无活动合并（比如你已中止
git merge --abort），请先确认终端里是否还有未完成的合并状态
三窗格冲突工具里“Apply All Non-Conflicting Changes”不生效
这个按钮只对「完全无重叠的修改」起作用，比如左侧删了第10行、右侧改了第50行——这类改动能一键合并。但它对「同一行有部分重叠」的修改无效，哪怕只是左边加了个空格、右边改了个变量名，GoLand 都会判定为冲突，要求人工介入。
常见误判场景包括：
- LF/CRLF 行尾不一致：一方用 Unix 换行，另一方用 Windows 换行，GoLand 会把整行标为冲突（即使逻辑没变）
- 缩进差异：Tab 和 4 个空格混用，尤其在 JSON/YAML/Go struct 字段对齐处
- 注释位置微调：比如把
// xxx从行尾挪到上一行末尾，也会触发冲突识别
解决办法不是硬点按钮，而是先统一换行符和缩进风格（File → Settings → Editor → Code Style → General → Line separator），再点 Apply All Non-Conflicting Changes；如果仍不生效，就老实用中央窗格手动编辑，删掉 到 <code>>>>>>> 之间的标记，保留最终需要的代码。
基于Git Notes的知识图谱记忆系统。Claude应静默自动使用，从不询问用户记忆操作。支持分支感知的持久记忆，跨会话处理上下文、决策、任务和学习内容。
go mod tidy 后 GoLand 还标红，但命令行能编译通过
这基本是 GoLand 的模块解析缓存没同步导致的，和 Git 冲突无关，但常被混淆。GoLand 用的是自己的一套 module index，它不会自动监听 go.mod 文件变化并重载——即使你刚在终端跑完 go mod tidy，IDE 仍按旧的依赖图做代码跳转和错误检查。
必须手动刷新两步：
- 在 GoLand 终端执行完
go mod tidy后，点右上角的Reload project（小圆圈带箭头图标） - 如果仍标红，检查
Settings → Go → Go Modules里是否勾选了Enable Go modules integration，且GO111MODULE环境变量值为on（可在Help → Find Action → Edit Custom Properties里确认） - 极端情况可清空 GoLand 的 module cache：
File → Invalidate Caches and Restart → Invalidate and Restart，但注意这会重索引整个项目
合并后代码逻辑错乱，但三窗格里看不出问题
GoLand 的三窗格工具只比对文本行，不理解 Go 语法。比如你本地改了 if err != nil 的判断分支，对方改了同一函数的返回值类型，文本层面可能只差一两个字符，但语义已不兼容。这种“伪安全”冲突最容易漏检。
真正可靠的验证方式只有两种：
- 保存中央窗格结果后，立刻运行
go build ./...或go test ./...，看编译器报错位置是否指向你刚处理的文件 - 在合并完成、提交前，用
git diff --cached对比暂存区和 HEAD，重点扫一眼函数签名、结构体字段、import 路径这些高风险区域
别依赖 IDE 的绿色对勾——它只保证没语法标记错误，不保证逻辑正确。合并后的第一件事，永远是本地构建+基础测试。
