GoLand更新依赖后不应盲目执行go clean -modcache；应优先让go mod tidy按需刷新缓存，仅在checksum mismatch等特定问题时精准清理单个模块，并执行go mod verify校验一致性。
GoLand 里更新依赖后，go clean -modcache 不是首选操作
GoLand 本身不管理模块缓存，它只是调用 Go 命令；真正决定要不要清、怎么清的，是你本地 go 工具链的行为。盲目执行 go clean -modcache 会强制重下所有模块，既慢又没必要——尤其当你只改了一个 require 行或加了个新 module。
更合理的做法是让 Go 自己“按需刷新”：
- 保存
go.mod后，GoLand 通常自动触发go mod tidy（取决于 Settings → Go → Modules 是否启用 Auto-sync） -
go mod tidy会删掉未引用的依赖、拉取新增的、校验go.sum，但**完全复用已有缓存**，不碰$GOMODCACHE里的源码目录 - 如果新模块拉不下来（比如私有仓库权限失效），错误在拉取环节，不是缓存“脏”，此时应先检查
go env GOPRIVATE和网络代理，而不是清缓存
遇到 checksum mismatch 或 unknown revision 才需要精准清理
这类报错往往不是因为“缓存太旧”，而是缓存里混了不同来源的同版本包（比如之前走 proxy.golang.org，现在走公司 Nexus），或者本地手动改过 $GOMODCACHE 下的源码。
这时该删的不是整个缓存，而是出问题的那个模块：
- 先确认路径：
go env GOMODCACHE（别直接硬写$GOPATH/pkg/mod，可能不一致） - 删模块源码：
rm -rf $(go env GOMODCACHE)/github.com/some/pkg@v1.2.3 - 删对应压缩包和校验数据：
rm -rf $(go env GOMODCACHE)/cache/download/github.com/some/pkg - 再执行：
go mod download github.com/some/pkg@v1.2.3，验证能否干净拉取
Windows 用户把 rm -rf 换成 rd /s /q，注意路径分隔符用 \。
go clean -cache 和 go clean -modcache 完全是两回事
很多人混淆这两个命令，结果清错了地方还怪 IDE：
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
-
go clean -cache清的是$GOCACHE（编译中间产物，如.a文件），影响构建速度，不影响依赖内容；GoLand 频繁保存时容易撑大这个目录 -
go clean -modcache清的是$GOMODCACHE（模块源码 + zip + 校验文件），影响的是“有没有这个版本的代码”，不是“编译快不快” - 你在 GoLand 里改了代码却没生效，大概率是
$GOCACHE没清，而不是$GOMODCACHE有问题
如果 GoLand 构建变慢或行为异常，优先跑 go clean -cache，不是 go clean -modcache。
真正容易被忽略的点：清理后不校验，等于白清
删完模块或整个 modcache 后，很多人直接 go build 就完事。但 Go 不会自动帮你核对新拉下来的包和 go.sum 是否一致——尤其是你用过 -replace 或私有代理时。
务必补上这一步：go mod verify。它会遍历所有模块，比对 go.sum 中记录的 checksum 和当前缓存里的实际内容。失败就说明拉错了、源被篡改、或 go.sum 本身已过期。
另外，go.sum 文件本身不会因清理缓存而更新；它只在 go mod download 或 go get 时由 Go 工具链写入。别指望删缓存能“修复”校验失败——得靠 go mod verify 暴露问题，再靠 go mod tidy 或手动 go mod download 修正。
