先确认GoLand中GOROOT、GOPATH、GOMODCACHE与终端go env输出一致，检查项目根目录有go.mod并启用Go Modules，再执行Invalidate Caches and Restart；若仍报错，排查replace、vendor或go.sum校验冲突。
GoLand 里提示模块找不到，先别急着删整个 modcache
绝大多数“模块找不到”不是缓存损坏，而是 GoLand 的索引或 GOPATH/GOMODCACHE 环境没对齐。它可能还在用旧的 GOPATH、没识别到当前项目启用了 Go Modules（GO111MODULE=on），或者 IDE 缓存了错误的 go list -m all 结果。
实操建议：
- 在 GoLand 中打开 File → Settings → Go → GOROOT / GOPATH，确认
GOPATH和GOMODCACHE路径与终端里go env GOPATH、go env GOMODCACHE输出一致 - 检查项目根目录是否有
go.mod；如果没有，右键目录 →Go → Initialize Go Module，否则 GoLand 默认走 GOPATH 模式，根本不会查$GOMODCACHE - 点击菜单 File → Invalidate Caches and Restart… → Invalidate and Restart，这清的是 GoLand 自己的符号索引缓存，不是 Go 的模块缓存，但能解决 80% 的“红色波浪线但实际能构建”的问题
- 终端里运行
go list -m all，看输出是否正常；如果报no required module provides package，说明是项目配置问题，不是缓存问题
go mod download 后仍提示 cannot find module，重点查 checksum 和 proxy 混用
这种错误往往发生在切换过私有代理（比如从 https://goproxy.cn 切到公司 Nexus）之后。缓存里存着同版本但不同来源的模块，go.sum 校验失败，Go 就拒绝加载——但它不直接报校验错，只说“找不到”。
实操建议：
- 运行
go mod verify，如果报missing hash in go.sum或mismatched hash，就是校验问题，不是路径问题 - 临时关闭校验验证：设置
GOSUMDB=off，再跑go mod download，看是否恢复；若恢复，说明是 sumdb 冲突，不是缓存损坏 - 清理对应模块的校验数据：删掉
$(go env GOMODCACHE)/cache/download/下整个目录（不只是/ @vX.Y.Z子目录），因为 .info/.ziphash 文件可能残留旧源记录 - 确认
go env GOPRIVATE已包含你的私有域名，否则 Go 会强制走 proxy + sumdb，导致私有模块被当成公共模块校验
只想重拉某一个模块，别用 go clean -modcache
go clean -modcache 会清空全部模块缓存，包括你正在开发的十几个依赖。CI 里用它没问题，但在本地开发中纯属浪费带宽和时间——尤其当你只是想重试 github.com/elastic/go-elasticsearch 的 v8.12.0。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
实操建议：
- 确认模块路径和版本号完全匹配：
go env GOMODCACHE+/github.com/elastic/go-elasticsearch@v8.12.0（注意：不是v8.12.0+incompatible） - Linux/macOS 执行：
rm -rf $(go env GOMODCACHE)/github.com/elastic/go-elasticsearch@v8.12.0；Windows 用rd /s /q "%GOMODCACHE%\github.com\elastic\go-elasticsearch@v8.12.0" - 再执行：
go mod download github.com/elastic/go-elasticsearch@v8.12.0，它会重建源码目录 + 下载 zip + 写 .info + 更新 sum.db - 如果下载卡住，加
-x参数看真实拉取地址：go mod download -x github.com/elastic/go-elasticsearch@v8.12.0
清理后 go build 还报 missing，大概率是 vendor 或 replace 残留
手动删了 $GOMODCACHE 里的模块，但项目里用了 replace 指向本地路径，或启用了 vendor，那 Go 构建时根本不会查缓存——它直接读 ./vendor 或 ./local/path。此时清缓存毫无意义，反而掩盖了真正的问题。
实操建议：
- 检查
go.mod里有没有replace行，尤其是=> ./some/local/dir这种；删了缓存后，它仍会尝试读那个本地目录，而该目录可能已被删或权限不对 - 运行
go list -m -f '{{.Replace}}' github.com/xxx/yyy，看是否非空；若返回./local，就去检查那个路径是否存在且可读 - 如果有
vendor目录，go build默认优先用它；想绕过 vendor 强制走模块缓存，加-mod=mod参数：go build -mod=mod - 最隐蔽的坑：
go.mod里写了require github.com/xxx/yyy v1.2.3，但go.sum里对应的是v1.2.3+incompatible的 hash；删缓存后go mod download会拉v1.2.3，但校验时比对的是+incompatible的 hash，必然失败——必须先go mod tidy同步版本语义
