go clean -modcache仅清理模块下载缓存（$GOPATH/pkg/mod），而GoLand的“Invalidate Caches”清除IDE自身索引、符号表等，二者作用域不同；需配合使用才能解决依赖标红、跳转失效等问题。
go clean -modcache 和 GoLand Invalidate Caches 是两回事
很多人以为 go clean -modcache 就等于清掉了 GoLand 的所有缓存，其实不是。前者只删 $GOPATH/pkg/mod 下的模块下载缓存，后者清的是 IDE 自己维护的索引、语法树、符号表等——比如你改了 go.mod 但 GoLand 还标红 import，大概率是后者没刷新。
常见错误现象：执行完 go clean -modcache 后重启 GoLand，依赖依然标红、跳转失效、go list 报错找不到包。
-
go clean -modcache要在项目根目录或任意路径下运行，全局生效；它不解决 IDE 索引错乱问题 - GoLand 的缓存存放在
~/Library/Caches/JetBrains/GoLand*（macOS）、%LOCALAPPDATA%\JetBrains\GoLand*（Windows）等位置，和 Go 工具链完全隔离 - 必须配合
File → Invalidate Caches and Restart → Invalidate and Restart才能重建项目语义索引
什么时候该用 Synchronize 而不是 Invalidate Caches
如果你只是新增/删除了几个文件、改了 go.work 或切换了 Go SDK 版本，Synchronize 更轻量、更快，且不会丢掉当前打开的编辑器标签和断点设置。
使用场景：
- 刚从 git pull 拉下新分支，发现某些文件没被识别为 Go 文件（图标不对、无补全）
- 手动移动了
go.mod到子目录，但 GoLand 还在旧路径下扫描 - 启用了
go.work但 IDE 没自动识别多模块结构
操作方式：右键项目根目录 → Synchronize，或按 Cmd + Option + Y（macOS）/Ctrl + Alt + Y（Windows/Linux）。注意：它不会重建整个索引，所以遇到深度解析失败（如泛型推导崩了）仍得走 Invalidate。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
Invalidate Caches 后项目仍加载失败？检查 Go Modules 配置是否同步
即使缓存清空、IDE 重启，如果 GoLand 没正确读取 go.mod，它会退化成纯文件浏览器——不解析 import、不校验类型、不提供 test 运行按钮。关键不在缓存，而在配置同步状态。
验证与修复步骤：
- 打开
Settings → Go → Go Modules，确认Enable Go Modules integration已勾选 - 检查
GO111MODULE是否为on（可通过终端执行go env GO111MODULE对比） - 若项目含
go.work，确保Settings → Go → Go Workspaces中已启用对应选项，并点击右侧Reload按钮 - 最后再右键项目根目录 →
Load project with Go Modules（此菜单项仅在检测到go.mod或go.work时出现）
频繁重载导致卡顿？关掉自动构建和后台索引干扰项
每次 Invalidate 或 Synchronize 都会触发全量索引，如果同时开着 Build project automatically 和 gopls 的深度分析，CPU 和磁盘 I/O 会瞬间拉满，看起来像“卡死”。这不是 bug，是功能叠加的副作用。
建议临时关闭：
-
Settings → Go → Build Tags & Vendoring → Build project automatically（关掉后需手动Ctrl + F9编译） -
Settings → Languages & Frameworks → Go → Language Server → gopls settings → build.ignore，填入bin/,pkg/,vendor/（避免对构建产物做语义分析） -
Settings → Editor → File Types → Ignore files and folders，加入**/bin/**;**/pkg/**;**/go-build/**（减少文件监听压力）
这些设置不影响代码功能，只降低 IDE 启动和重载时的资源争抢。真正容易被忽略的是：gopls 的 build.ignore 默认为空，一旦项目生成大量 bin/xxx，它就会反复尝试解析并失败，拖慢整个重载流程。
