goland的go缓存和ide缓存是两回事，前者指go工具链的$gocache和$gomodcache，后者是jetbrains自维护的索引、符号表等；ide卡顿、跳转错、补全失效多因ide缓存损坏或gopls状态混乱，需先invalidate caches and restart，再确保goroot、goproxy、vendor配置正确，并重载模块与重启gopls。
GoLand 的 Go 缓存和 IDE 缓存是两回事
很多人以为「GoLand 提示卡、跳转错、补全不出现」是 Go 工具链的问题，其实八成出在 IDE 自身缓存——比如索引损坏、模块解析残留、或旧版 gopls 语言服务器状态混乱。GoLand 不会自动同步 go env 变更，也不会感知你刚删了 $GOPATH/pkg/mod，它只认自己 cache 目录里存的符号表。
清 GoLand 自身缓存的正确操作顺序
直接删 ~/.cache/JetBrains/GoLand2024.2（版本号按实际）最彻底，但容易误删配置。推荐分步清理：
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 先在 GoLand 中执行 File → Invalidate Caches and Restart → Invalidate and Restart（不是 “Just Restart”）
- 重启后若仍异常，再手动删
~/.cache/JetBrains/GoLand*/index和~/.cache/JetBrains/GoLand*/localHistory（保留options目录防丢设置） - 检查是否启用了错误的 Go SDK：打开 Settings → Go → GOROOT，确认路径指向当前
which go输出的目录，而非旧版/usr/local/go-1.19或~/.gvm下的废弃路径 - 如果用了自定义
GOPROXY或GOPRIVATE，需在 Settings → Go → Modules 里显式填入，否则gopls启动时会 fallback 到默认代理，导致模块解析超时、提示延迟
为什么清理后还要重载模块和重启 gopls
GoLand 的代码提示底层靠 gopls，而 gopls 会缓存模块依赖图和类型信息。仅清 IDE 缓存不等于重置 gopls 状态：
- 执行 File → Close Project，再重新 Open 项目（不是 Reopen），强制
gopls重建 workspace - 在项目根目录下运行
go mod tidy，确保go.sum和依赖树一致；否则gopls会因校验失败静默降级功能 - 检查
gopls版本是否匹配当前 Go：运行go install golang.org/x/tools/gopls@latest，然后在 Settings → Go → Language Server 中勾选 “Use custom gopls binary”，指向$(go env GOPATH)/bin/gopls - 若项目含
//go:build条件编译，gopls默认只加载build tags为linux,amd64的文件；需在 Settings → Go → Build Tags & Directives 中手动添加所需 tag（如darwin或test）
容易被忽略的硬伤点：GOROOT 和 GOPATH 混用残留
GoLand 对 GOROOT 敏感，但对 GOPATH 已弱依赖——问题常出在历史配置残留：
- 检查
go env GOPATH输出是否为默认路径（如$HOME/go），若仍是旧路径（如/opt/go-workspace），说明 shell 配置里还有export GOPATH=，GoLand 继承了该环境变量，会错误地把$GOPATH/src当作 legacy module root 扫描 - GoLand 的 Run Configurations 里可能存了旧的
GOOS/GOARCH环境变量，导致gopls加载了错架构的 stdlib 符号，补全时漏掉runtime或os的方法 - 如果项目用了
vendor/，必须在 Settings → Go → Vendor 中勾选 “Enable vendoring support”，否则gopls会绕过vendor/直接查$GOMODCACHE，而你刚清过go clean -modcache，结果就是“找不到包”
gopls 拿到的模块视图和 IDE 索引没对齐——清缓存只是第一步，后续必须让工具链和 IDE 在同一套环境变量、同一份依赖快照下重新握手。
