go clean -cache 清的是 $GOCACHE 目录下的编译中间产物（如 .a 文件），用于加速 go build/go test，不清理 $GOMODCACHE 或 IDE 缓存；执行后首次构建变慢属正常，且若设 GOCACHE=off 则该命令静默无效。
GoLand 本身不管理 Go 缓存，所谓“孤立缓存文件”基本都来自 Go 工具链（go build、go test、go mod download），不是 IDE 自己生成的。直接在 GoLand 设置里点“Clear cache and restart”只清 IDE 自身索引，对 $GOCACHE 和 $GOMODCACHE 完全无效。
go clean -cache 清的是什么、为什么它不自动触发
go clean -cache 删除的是 $GOCACHE 目录下所有已编译的中间产物（.a 文件），这些是 go build 和 go test 为加速重复构建而缓存的。GoLand 不调用这个命令——它只调用 go list 或 go build -o /dev/null 做语法检查，不会主动清理。
- 默认路径：
~/Library/Caches/go-build（macOS）、%LOCALAPPDATA%\go-build（Windows）、$XDG_CACHE_HOME/go-build（Linux） - 执行后首次构建变慢是正常现象，缓存重建需要时间
- 如果设了
GOCACHE=off，该命令静默不做任何事 - 它不删
$GOPATH/pkg/mod，也不影响模块下载
哪些缓存必须手动删，go clean 不覆盖
GoLand 的“Build project automatically”开关开着时，会高频触发 go list 和 go build，间接往 $GOCACHE 写大量小文件；但有些缓存根本不在 go clean 范围内，得手动处理：
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
-
~/Library/Caches/JetBrains/GoLand*：IDE 自身的符号索引、代码补全缓存，go clean完全不碰 -
~/Library/Application Support/JetBrains/GoLand*：用户配置、插件、模板，重装前必须清，否则新版本加载旧设置导致项目识别失败 -
~/Library/Logs/JetBrains/GoLand*：日志文件可能占几 GB，尤其开启goplsdebug 后 -
~/Library/Saved Application State/com.jetbrains.goland.savedState：欢迎页卡住、窗口布局错乱的常见元凶
误删 $GOPATH/pkg/mod 会导致什么
有人看到 $GOPATH/pkg/mod 占几十 GB，顺手 rm -rf，结果下次 go run main.go 开始疯狂下载依赖。这不是 bug，是设计使然：
-
go clean -modcache是唯一安全方式；手动删会破坏符号链接一致性（比如github.com/user/repo@v1.2.3指向一个含哈希的伪版本目录） - 残留的
.info文件可能指向已删除的.zip，触发后续go mod verify失败 - 若用过
go mod edit -replace，本地替换关系靠软链接维持，手动删后go build可能拉错远程版本 - 真正该监控的是
go env GOMODCACHE输出路径，不是硬编码$GOPATH/pkg/mod
扫描“孤立”文件的实操建议
没有通用工具能自动识别哪些缓存“孤立”，因为 Go 不记录谁用了哪个 .a 文件。但你可以结合上下文缩小范围：
- 先确认当前
go env GOCACHE和go env GOMODCACHE路径，避免扫错目录 - 用
find $GOCACHE -type f -name "*.a" -mtime +30 | head -20看是否真有超 30 天未访问的.a文件（注意：mtime不可靠，Go 缓存不更新时间戳） - 更稳妥做法是定期执行
go clean -cache -fuzzcache，再配合du -sh $GOCACHE验证是否清空 - 别用
find ~ -iname "*goland*" -type d扫描——Toolbox 自动部署的实例名带哈希，匹配不到，反而漏关键目录
最常被忽略的一点：GoLand 启动时读取的 shell 环境变量（比如 GOPATH、GOROOT）可能来自 ~/.zshrc 里早被遗忘的旧配置，清理完缓存却仍加载错误 SDK，问题根源其实在这里。
