ambiguous import错误源于同一导入路径被多个模块声明不同版本，需用go list、go mod graph定位冲突，通过require统一版本并replace强制归一，再执行go mod tidy清理。
编译报错显示“ambiguous import”或“cannot load package”
这通常不是 Git 冲突，而是 Go 编译器在解析 import 路径时发现多个模块提供了同名包（比如两个不同路径的 github.com/sirupsen/logrus 和 github.com/Sirupsen/logrus），或者同一路径被不同版本模块同时声明。GoLand 本身不参与版本解析，但它会把底层 go build 或 go list 的错误原样展示出来。
先别急着改代码，打开终端执行：
-
go list -m all | grep logrus（把logrus换成你报错里的包名）——看是否真有多个版本共存 -
go mod graph | grep logrus——查清楚谁拉进了哪个版本、路径是否大小写不一致（Sirupsenvssirupsen是经典坑） - 检查
go.mod里有没有残留的旧 require 行，尤其是带// indirect的，它们可能锁死了冲突版本
GoLand 的 “Reload project” 按钮不起作用
很多人点完右上角的 ? 就以为依赖刷新了，其实它只重新读取 go.mod 文件结构，不会触发 go mod tidy 或版本重解。真正生效的操作必须手动执行：
- 在 GoLand 终端里运行
go mod tidy，观察输出是否删掉了冗余require或修正了版本 - 如果 tidy 后仍报错，说明存在无法自动协调的版本矛盾，这时需要人工干预：在
go.mod中加replace或显式require - 改完
go.mod后，**必须再点一次 Reload project**，否则 GoLand 的索引和代码跳转仍按旧状态工作
replace 写对了但 GoLand 还是标红、跳转失效
replace 生效的前提是 GoLand 使用的 Go SDK 和模块解析上下文与命令行一致。常见断点：
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 确认 GoLand 设置里的 Go SDK 路径和
which go输出一致；若用了 asdf、gvm 等多版本管理器，要选对 shell 初始化后的环境 - 检查
GO111MODULE=on是否已全局启用（go env GO111MODULE应输出on），否则 GoLand 可能 fallback 到 GOPATH 模式，忽略replace - 本地路径
replace github.com/xxx => ./fix在 GoLand 里需确保./fix是项目根目录下的相对路径，且该目录包含有效的go.mod - 如果用了私有仓库，
GOPRIVATE必须配置（如GOPRIVATE=git.example.com/*），否则 GoLand 仍尝试走 proxy，导致 replace 不触发
为什么 CI 通过但 GoLand 里一直报错
最常被忽略的一点：GoLand 默认使用自己的 module cache 和 build cache，和 CI 容器里干净的 $GOCACHE 不一致。尤其当你本地执行过失败的 go get 或手动修改过 vendor/，缓存可能卡在中间态。
安全清理方式：
- 在 GoLand 终端运行
go clean -modcache（清模块缓存） - 再运行
go mod download强制重拉所有依赖 - 最后点 File → Invalidate Caches and Restart… → Just Restart（不是 Clear and Restart，避免丢失设置）
- 重启后首次加载会慢一点，这是正常现象——它在重建符号索引，等进度条消失再看报错是否还在
真正麻烦的从来不是怎么写 replace，而是没意识到 GoLand 的缓存、环境变量、SDK 配置三者之间存在隐性耦合。每次改完 go.mod，都得验证终端命令和 IDE 状态是否同步，缺一不可。
