“ambiguous import”或“cannot load package”错误源于Go模块解析失败，非IDE问题；需用go list -m all、go mod graph、go mod why定位冲突路径（大小写、v2后缀、协议差异等），再通过go get升级、require统一或replace接管路径，并执行go mod tidy和Reload project确保同步。
GoLand 报“ambiguous import”或“cannot load package”，不是 IDE 故障，而是底层 go build 在模块解析阶段就失败了——它压根没机会走到编译器，所以调 IDE 设置、换 SDK、点 Reload 都不解决根本问题。
先确认是不是真有多个同名模块在共存
别信报错里写的包名，大小写、路径前缀、v2 后缀都可能被当成不同模块。打开 GoLand 内置终端，执行：
-
go list -m all | grep -i logrus（把logrus换成你报错里的包名）——看是否出现github.com/sirupsen/logrus和github.com/Sirupsen/logrus同时存在 -
go mod graph | grep -E 'logrus@|logrus.*@'——查清楚哪些模块拉进了哪个版本，尤其注意带/v2或/v3的路径是否混用 -
go mod why -m github.com/sirupsen/logrus——确认这个包是不是你代码里直接 import 的，还是被某个间接依赖硬塞进来的
go mod tidy 不会升级版本，必须用 go get 触发 MVS 重算
go mod tidy 只清理冗余 require，不会改变已锁定的版本。真正能推动版本变更的只有 go get：
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 只升目标包：运行
go get github.com/sirupsen/logrus@v1.9.3 - 连带升级其全部依赖：加
-u参数，go get -u github.com/sirupsen/logrus@v1.9.3 - 执行后立刻验证：
go list -m github.com/sirupsen/logrus输出应为v1.9.3，且go.mod和go.sum中对应条目已更新
replace 生效有严格前提，常见失效场景
replace 不是补丁，是路径接管。以下情况它会静默失效：
- GoLand 使用的 Go SDK 路径和终端里
which go不一致（比如用了 asdf 但没在 IDE 环境里初始化） -
GO111MODULE=off——检查go env GO111MODULE必须是on，否则 replace 被忽略 - 本地路径 replace 写成
./fix，但实际目录是../logrus-fix，且该目录下没有go.mod - 私有仓库没配
GOPRIVATE，导致 GoLand 仍走 proxy，绕过 replace
GoLand 的 Reload project 不等于重新解析模块
点右上角那个刷新图标，只是重读 go.mod 文件结构，不会触发 go mod tidy 或清除缓存。必须手动做两件事：
- 在终端运行
go mod tidy（如果 tidy 后仍有冲突，再加replace或require） -
改完
go.mod后，必须再点一次 Reload project，否则代码跳转、类型提示、标红都还按旧状态工作 - 如果 CI 能过但 GoLand 一直红，大概率是本地
$GOCACHE或$GOPATH/pkg/mod卡在中间态，可临时执行go clean -modcache再 tidy
最常被忽略的点：GoLand 里看到的 import 路径、跳转目标、错误提示，全依赖它当前索引的模块解析结果；而这个结果必须和命令行 go list -m 输出完全一致才算生效。任何一步没对齐，都会表现为“明明改了却没用”。
