根本原因是GoLand缓存清理与模块同步未联动：go clean -modcache仅清空$GOMODCACHE，但GoLand不会自动重解析go.mod；必须手动右键项目根目录→Synchronize或File→Reload project，并确认Enable Go Modules integration已启用且GOPROXY一致。
GoLand 清理缓存后依赖标红、go mod tidy 不生效、甚至 go build 报 cannot find module，根本原因不是缓存没清干净，而是缓存清理和模块同步的顺序/范围不匹配。
为什么 go clean -modcache 后依赖还“找不到”
执行 go clean -modcache 只清空 $GOMODCACHE（默认 $GOPATH/pkg/mod），它不碰 go.mod、go.sum 或本地 vendor 目录。但 GoLand 在缓存清理后不会自动触发模块重解析——它仍按旧状态索引代码，导致 import 路径标红、跳转失败。
- GoLand 的代码索引和依赖图是独立于 Go 工具链的，仅靠
go clean -modcache不会刷新 IDE 内部状态 - 如果你在清理前已修改过
go.mod（比如重命名模块、切 GOPROXY），缓存清了，但 IDE 还没重新读取该文件 - 某些情况下
go.mod里存在语法错误或版本格式异常（如v1.2.3+incompatible没对应实际 tag），go mod tidy表面成功，实则跳过修复
GoLand 同步模块必须手动触发
清理完 $GOMODCACHE 后，不能只等 IDE 自动响应。必须显式让 GoLand 重新加载模块配置：
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 右键项目根目录 → Synchronize（不是 “Reload project”）
- 或者：菜单栏 File → Reload project（仅对新版本 GoLand 有效；旧版需用 Synchronize）
- 如果项目用了
vendor，确保go mod vendor已执行且vendor/目录存在，否则 GoLand 默认忽略 vendor 模式 - 检查 GoLand 设置：Settings → Go → Go Modules → 确认勾选了 Enable Go Modules integration，且
GOPROXY值与终端一致（比如https://goproxy.cn,direct）
go mod tidy 失败时的定位步骤
当 go mod tidy 在终端报错或静默退出，而 GoLand 依然标红，说明模块声明层出了问题，不是缓存问题：
- 先运行
go list -m all：看输出里有没有(incompatible)、missing或路径明显异常的模块（比如github.com/xxx/yyy@none） - 检查
go.mod开头的module行是否与当前项目实际路径一致（尤其重命名、迁移后） - 删掉
go.sum后再跑go mod tidy：go.sum校验失败时可能阻塞下载，但删除后首次tidy会重建它 - 临时关闭代理验证：设
GOPROXY=direct再试一次go mod tidy，排除代理返回脏数据或 404 导致的卡住
容易被忽略的环境一致性陷阱
GoLand 和终端用的 Go 环境可能不同——这是最隐蔽的故障源：
- 在 GoLand 终端里执行
which go和go env GOPATH，对比系统终端输出，确认两者指向同一套 Go 安装和GOPATH - GoLand 默认可能使用 Bundled SDK，但你终端用的是
asdf或gvm管理的 Go 版本，GOOS/GOARCH或CGO_ENABLED差异会导致模块解析结果不一致 - 如果项目含
cgo依赖，清理缓存后必须确保CGO_ENABLED=1（或按需设为 0）再跑go mod tidy，否则部分模块不会被纳入解析范围
