GoLand反编译存根缓存位于IDE系统目录：macOS在~/Library/Caches/JetBrains/GoLand/decompiled-stubs，Windows在%LOCALAPPDATA%\JetBrains\GoLand\decompiled-stubs，Linux在~/.cache/JetBrains/GoLand/decompiled-stubs，该缓存独立于Go工具链的$GOCACHE和$GOMODCACHE，需手动删除以刷新过期存根。
GoLand 反编译存根缓存存在哪
GoLand 本身不生成反编译源码，它依赖 Go SDK 的 go list 和 go build 获取符号信息；当你点进标准库或未提供源码的第三方模块（比如某些私有二进制分发包）时，IDE 显示的“源码”其实是 GoLand 根据 .a 文件或导出符号自动生成的 stub（存根），这类内容缓存在 IDE 自己的系统目录里，不是 $GOCACHE 或 $GOMODCACHE。
路径取决于操作系统：
- macOS：
~/Library/Caches/JetBrains/GoLand/decompiled-stubs - Windows：
%LOCALAPPDATA%\JetBrains\GoLand\decompiled-stubs - Linux：
~/.cache/JetBrains/GoLand/decompiled-stubs
这个目录下是按模块路径组织的 .go 文件，内容类似：func Println(a ...interface{}) (n int, err error) —— 没有实现，仅签名。它不会被 go clean 命令触达。
手动删 decompiled-stubs 目录就能刷新存根
GoLand 不提供菜单项或设置开关来清空这部分缓存，也没做自动失效逻辑。一旦你更新了某个依赖的版本，或切换了 Go SDK，旧存根可能继续显示、甚至和新 API 冲突（比如方法名变了但 stub 还是老的），这时候必须手动清理。
操作步骤：
- 关闭 GoLand
- 找到对应
decompiled-stubs目录（注意版本号要匹配当前正在用的 GoLand，比如GoLand2024.3） - 执行
rm -rf decompiled-stubs（macOS/Linux）或rd /s /q decompiled-stubs（Windows） - 重启 GoLand，首次跳转到无源码包时会重新生成 stub
不用等它自己更新——它根本不会。
为什么改了依赖版本，GoLand 还显示旧函数签名
常见现象：升级 github.com/sirupsen/logrus 到 v1.10.0 后，logrus.WithError() 方法签名已变，但 GoLand 跳转进去仍显示老参数列表。这不是 Go 缓存问题，也不是 go mod download 没生效，而是 decompiled-stubs 目录里还留着 v1.8.0 生成的 stub 文件，且 GoLand 默认复用、不校验版本一致性。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
关键点：
- stub 文件名不含版本号，只按模块路径命名（如
github.com/sirupsen/logrus/logrus.go） - 没有时间戳或哈希校验，无法感知底层 .a 或模块源是否更新
- 即使你删了
$GOMODCACHE，stub 仍存在，IDE 不会主动重建
所以只要怀疑存根过期，第一反应就是删 decompiled-stubs，别在 Go 缓存命令里兜圈子。
删 stub 后首次跳转变慢，但不会影响构建
删除后重启 GoLand，第一次点击某个无源码包里的符号（比如 net/http.ServeMux），IDE 会卡顿 1–3 秒——这是它在解析 .a 文件、提取导出符号、生成新的 stub。后续就恢复正常。
注意：
- 这和
go build完全无关，不涉及$GOCACHE或编译过程 - 不会导致项目编译失败，也不会改变
go.mod或依赖行为 - 如果你用的是 vendor 或本地源码，GoLand 会直接打开真实文件，根本不走 stub 流程
真正容易被忽略的是：这个缓存藏得深、不暴露在设置里、也不响应任何 Go 命令，只能靠手动定位删除。很多人折腾半天 go clean -modcache 或重装 SDK，其实该删的是 JetBrains 自己的目录。
