GoLand卡顿主因是JVM内存不足与缓存冲突；需调高-Xms/-Xmx、禁用G1GC、关闭非核心检查器、优化gopls配置、精简文件监听，并区分清理IDE缓存、$GOCACHE和$GOMODCACHE。
GoLand 卡顿真凶不是代码，是 JVM 堆和缓存打架
GoLand 卡顿 90% 和你写的 Go 代码无关，而是它自己运行的 JVM 内存不足 + 缓存堆积导致频繁 GC、索引卡死、光标延迟。清理「无用缓存」不能只盯着 go clean，得先分清：IDE 自身缓存（JVM 级）、Go 构建缓存（$GOCACHE）、模块缓存（$GOMODCACHE）三者完全不互通，误删会拖慢构建甚至破坏依赖。
先清 GoLand 自身的 IDE 缓存和配置残留
这是最常被跳过的一步——重装或调参前不清掉旧配置，新版本照样继承卡顿。尤其当你换过 Go SDK、升级过插件、或从 Toolbox 迁移过实例时：
- 执行
File → Invalidate Caches and Restart… → Just Restart，这是最快捷的轻量清理，适合日常卡顿后立即操作 - 若问题顽固，必须手动删用户级目录：
rm -rf ~/Library/Caches/JetBrains/GoLand*（macOS）rm -rf ~/.cache/JetBrains/GoLand*（Linux）del /s /q "%LOCALAPPDATA%\JetBrains\GoLand*"（Windows CMD） - 别漏掉配置目录：
rm -rf ~/Library/Application\ Support/JetBrains/GoLand*，否则主题、快捷键、gopls 设置全复活 - 删完重启前，检查
~/.zshrc或~/.bash_profile是否残留export GOPATH=...或GOROOT=...，这些会干扰 gopls 初始化
再清 Go 构建缓存 $GOCACHE，别让它悄悄涨到 30GB+
go clean -cache 是唯一安全、可逆、不影响模块下载的清理方式。它只动 $GOCACHE（默认 macOS 在 ~/Library/Caches/go-build），删的是编译中间产物（.a 文件），不是源码也不是模块。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 直接终端执行：
go clean -cache，无需进项目目录，全局生效 - 如果用了模糊测试，顺手加一句：
go clean -fuzzcache - 想彻底清空（比如 CI 机器或磁盘告急）：
rm -rf $(go env GOCACHE)/*，注意末尾的/*，漏掉就白删 - 设了
GOCACHE=off？那go clean -cache什么也不做，得先unset GOCACHE - 清理后首次
go build变慢是正常现象，缓存重建需要时间，之后速度恢复
别碰 $GOMODCACHE，除非你真要重拉所有依赖
go clean -modcache 删的是 $GOMODCACHE（默认 $GOPATH/pkg/mod），也就是所有已下载解压的模块源码和校验数据。这不是“缓存”，是 Go Modules 的本地仓库。
- 常见误操作：看到
$GOPATH/pkg占空间大，rm -rf $GOPATH/pkg一把梭——结果下次go run开始疯狂下载，还可能触发checksum mismatch - 只在明确需要重置模块状态时才用：
go clean -modcache，且务必确认GO111MODULE=on，否则静默无效 - 只想删某个模块？手动删更可控：
rm -rf $GOMODCACHE/github.com/xxx@v1.2.3和$GOMODCACHE/cache/download/github.com/xxx - 删完立刻跑
go mod verify，确保后续拉取的模块和go.sum一致
真正卡顿的根源往往藏在 JVM 配置里——-Xmx 设太小、-XX:ReservedCodeCacheSize 不足、或者 vendor 目录被 IDE 当普通源码反复扫描。这些比删缓存更关键，也更容易被忽略。
