真正生效的版本必须用go list -m all确认，goland依赖视图不反映mvs结果；改go.mod后需手动执行go mod tidy，sync按钮不能替代go get；replace仅影响路径解析，不影响依赖树结构。
查清实际加载的是哪个版本，别信go.mod里写的
GoLand 的依赖视图（Project Structure → SDKs → Go Libraries）只显示项目声明的 require，不反映 MVS 算法最终选中的版本。真正生效的版本必须用命令确认：go list -m all | grep github.com/sirupsen/logrus。如果输出里带 =>（如 github.com/sirupsen/logrus v1.9.3 => ./local-fix），说明 replace 生效；如果只有 v1.8.1，那 go.mod 里写的 v1.9.3 就是被更高优先级约束压住了。
在GoLand里改go.mod后必须手动触发go mod tidy
GoLand 编辑 go.mod 文件时不会自动运行 go mod tidy，哪怕你加了 replace 或改了 require。这会导致 IDE 显示“已更新”，但 go.sum 没写入新校验和、本地缓存没刷新、构建仍用旧版。必须手动执行：
- 右键项目根目录 → Go → Run 'go mod tidy'
- 或打开 Terminal，运行
go mod tidy - 完成后检查
go.sum是否新增了对应模块的校验和条目
GoLand的“Sync”按钮不能替代go get
点击右上角的 Sync 图标（两个箭头绕圈）只会重新解析 go.mod 和下载缺失模块，它不会触发 MVS 重计算，也不会升级已有依赖。比如你想把 logrus 从 v1.8.1 升到 v1.9.3，仅 Sync 没用。必须用命令：
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
-
go get github.com/sirupsen/logrus@v1.9.3（只升该模块） -
go get -u github.com/sirupsen/logrus@v1.9.3（连带升其所有依赖）
执行后再 Sync，IDE 才能正确索引新版本的符号。
调试时用replace指向本地路径，但别提交到CI
在 GoLand 中调试一个未发版的修复分支时，replace github.com/sirupsen/logrus => ../logrus-fix 是最快方式。但要注意：
- 本地路径必须存在且含有效
go.mod，否则 GoLand 报cannot find module - GoLand 的 Run Configuration 里要勾选 “Include modules from vendor directory”（如果用了 vendor）
- 绝对不要把
replace ... => ../xxx提交到 Git —— CI 构建时路径不存在，直接失败 - 上线前务必换成 fork 的 tag 版本，例如
replace github.com/sirupsen/logrus => github.com/yourname/logrus v1.9.3-fix
最常被忽略的一点：replace 只影响 import 路径的解析，不改变依赖树结构。如果你看到 go mod graph 里仍有旧版本边，但 go list -m all 已显示新版本，说明它只是“画布上的旧线”，实际构建已接管——别被 graph 的表象骗了。
