GoLand不管理Go模块缓存，仅调用go命令；真正控制缓存路径的是GOMODCACHE环境变量，清理需执行go clean -modcache或手动删除对应目录，IDE重载项目不影响磁盘缓存。
GoLand 本身不管理 Go 模块缓存，它只是调用 go 命令
GoLand 没有独立的“包缓存”概念，它依赖的是 Go 工具链自身的缓存机制。你看到的依赖下载、补全、跳转等行为，背后全是 go mod download、go list 和 $GOMODCACHE 在工作。IDE 只是把命令封装进 UI（比如点击 “Sync dependencies” 就是执行 go mod tidy），但缓存文件本身不在 GoLand 安装目录里，也不归它清理。
真正要清的是 $GOMODCACHE，不是 GoLand 的 cache 目录
很多人误删 $HOME/Library/Caches/JetBrains/GoLand2026.2（macOS）或 %LOCALAPPDATA%\JetBrains\GoLand2026.2\cache（Windows），这只会让 IDE 重索引项目，对依赖下载毫无影响——go build 照样从 $GOMODCACHE 拿源码，哪怕 GoLand 的索引全空了。
- 确认路径：
go env GOMODCACHE（常见为$GOPATH/pkg/mod） - 安全清理全部：
go clean -modcache（Go 1.12+ 支持，幂等，只删模块缓存） - 精准清理单个依赖：
rm -rf $(go env GOMODCACHE)/github.com/sirupsen/logrus@v1.14.0（Linux/macOS）；Windows 用rd /s /q "%GOMODCACHE%\github.com\sirupsen\logrus@v1.14.0" - 删完别忘了补校验：
go mod verify，否则go.sum和新拉的包可能不一致
为什么在 GoLand 里点 “Reload project” 不等于清理缓存
GoLand 的 “Reload project” 或 “Sync dependencies” 只会触发 go list -m all 和 go mod graph，用于更新 IDE 内部依赖图和符号索引。它不会删除任何磁盘上的 .zip 或解压源码，也不会绕过本地缓存去重拉远程包。如果你遇到：
-
go list -m all显示的版本和go.mod对不上 - 改了
replace后补全还是旧代码 - 切换私有代理后
go mod download报checksum mismatch
这些都不是 IDE 的问题，而是 $GOMODCACHE 里混着不同来源的同版本包。必须手动删对应目录或跑 go clean -modcache。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
CI 或多项目环境下慎用 go clean -modcache
全量清理看似彻底，但在共享构建节点或本地多项目共用 $GOMODCACHE 时，代价很高：下次所有项目首次构建都会重新下载几十个公共依赖（如 golang.org/x/sys、google.golang.org/protobuf）。更轻量的做法是：
- 先用
go list -m -json all | jq -r '.Path'提取当前项目实际用到的模块名 - 对比
ls $(go env GOMODCACHE)，只删那些不在列表里的@version目录 - 对私有域名（如
git.internal.company.com），定期检查$(go env GOMODCACHE)/cache/download/下是否残留已下线项目的缓存
真正容易被忽略的是：删完模块目录后，cache/download/ 下的 .info 和 .ziphash 文件不会自动重建，得靠 go mod download 触发；而如果网络中断或权限不足，这个过程会静默卡住，看起来像“清理没生效”。
