GoLand标红是因未刷新依赖状态，需先执行go mod tidy更新go.sum，再点击右上角Reload project重建索引；漏任一步均会导致标红和跳转失效。
go.mod里版本写对了，GoLand里还是标红
不是代码写错了，是GoLand没真正加载你改过的依赖状态。它只读go.mod结构，不自动执行解析和缓存刷新。
必须手动触发两步：go mod tidy（解决版本冲突、补全go.sum）→ 再点 GoLand 右上角的 Reload project（重建索引和跳转映射）。漏掉任意一步，标红和跳转失效都会持续。
常见断点：
-
go env GO111MODULE输出不是on：GoLand 会 fallback 到 GOPATH 模式，无视replace和require - GoLand 设置里的 Go SDK 路径和终端
which go不一致：尤其用了asdf或gvm时，要选 shell 初始化后的那个 SDK -
replace指向本地路径（如./fix），但该目录下没有合法go.mod（module 声明必须和原路径一致）
go list -m all 显示多个同名包不同版本
这不是“冲突”本身，而是依赖图快照——go mod graph 会把所有引入路径都列出来，包括被 MVS 算法最终丢弃的版本。关键要看哪个版本被实际加载。
运行：go list -m github.com/sirupsen/logrus 查当前生效版本；再用 go mod why github.com/sirupsen/logrus 看谁把它拉进来。如果输出里出现测试工具（如 ginkgo）或 linter（如 staticcheck），优先升级这些工具本身，而不是硬 patch 主项目。
大小写敏感是经典坑：github.com/Sirupsen/logrus 和 github.com/sirupsen/logrus 是两个模块，Go 不做归一化。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
CI 构建成功，但本地 GoLand 一直报错
根本原因不是代码差异，而是缓存不一致。GoLand 默认复用本地 $GOCACHE 和模块缓存，而 CI 容器是干净环境。尤其当你本地执行过失败的 go get 或手动改过 vendor/，缓存可能卡在中间态。
验证方式：在 GoLand 终端里运行 GO_CACHE=$(mktemp -d) go build，如果这时不报错，就确认是缓存污染。
生产级清理建议：
- 删掉
$GOPATH/pkg/mod/cache和$GOCACHE（或用go clean -modcache && go clean -cache） - CI 流水线中强制用
go mod vendor+go build -mod=vendor，彻底绕过在线解析 - 私有模块必须全局配
GOPRIVATE=git.internal.company.com/*，否则任一节点漏配就会 fallback 到 proxy 并静默失败
go mod tidy 后仍提示 inconsistent dependencies
说明 go.mod 里存在无法协调的约束，比如手动写了两条冲突的 require 行，或某个子模块（如 ./internal/foo）单独跑了 go mod init，生成了独立 go.mod 却没同步主模块版本。
实操顺序：
- 删掉所有重复或明显过时的
require行，只留一个明确语义化版本（如v1.9.0，别写v1.9） - 临时去掉
replace：go mod edit -dropreplace github.com/xxx/yyy，看是否恢复一致性 - 若必须用
replace，确保目标路径下有合法go.mod，且能被go list ./扫描到 - 终极手段：删掉
go.sum和go.mod，重新go mod init+go get逐个加依赖
容易被忽略的是：v2+ 版本升级后，import 路径必须同步改（如从 github.com/a/b 改为 github.com/a/b/v2），否则编译期不报错，运行时才 panic。
