不是项目本身大，而是GoLand索引服务因JVM堆内存不足频繁GC导致卡顿；需同步调高-Xms、-Xmx和-XX:ReservedCodeCacheSize，并检查GOPROXY/GOSUMDB配置、清理构建缓存、避免init()中阻塞操作。
GoLand 启动/打开项目卡在 indexing 或无响应，先看是不是 JVM 内存不够
不是项目本身大，而是 GoLand 的索引服务吃光了默认堆内存。尤其开了 vendor、用了 go.work、或引入 kubernetes/client-go 这类巨量接口的模块时，2GB 堆根本撑不住——JVM 频繁 GC，UI 线程被挂起，表现为输入延迟、提示不弹、状态栏一直显示 “indexing…”。
必须同步调高三个参数：-Xms（初始堆）、-Xmx（最大堆）、-XX:ReservedCodeCacheSize（代码缓存）。只加 -Xmx 会启动抖动，不加 -XX:ReservedCodeCacheSize 则 JIT 编译器很快耗尽空间。
- 编辑
goland64.vmoptions，填入：-Xms2g -Xmx4g -XX:ReservedCodeCacheSize=512m
- macOS 路径：
~/Library/Caches/JetBrains/GoLand2026.1/goland64.vmoptions（注意版本号匹配） -
-Xmx别超6g：超过后 G1GC 停顿时间非线性增长，反而更卡 - 删掉所有含
-XX:+UseG1GC的行——GoLand 官方明确不推荐手动指定 GC 策略
GoLand 打开项目后反复扫描、提示变慢，检查 GOPROXY 和 GOSUMDB 是否错配
如果 go list -m all 在终端卡住，或 GoLand 底部状态栏长期显示 “Resolving dependencies”，大概率是模块校验失败导致重试风暴。典型错误是只设了 GOPROXY=https://goproxy.cn，但没配对应 GOSUMDB，结果每次校验都 fallback 到不可达的 sum.golang.org，超时后重试，拖垮整个索引流程。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 运行
go env GOPROXY GOSUMDB，确认二者同源：export GOPROXY=https://goproxy.cn,direct export GOSUMDB=gosum.io+ce6e7565+https://goproxy.cn/sumdb
- 私有模块必须加
GOPRIVATE=github.com/my-org/*，否则 go 命令会坚持走代理校验，报checksum mismatch - 临时验证：在项目根目录执行
GOPROXY=https://goproxy.cn GOSUMDB=gosum.io+ce6e7565+https://goproxy.cn/sumdb go mod download，看是否秒完成
GoLand 构建产物越积越多，磁盘爆满，别乱删 $GOPATH/pkg/mod
$GOCACHE（如 ~/Library/Caches/go-build）和 $GOPATH/pkg/mod 是两套独立缓存，作用完全不同。误删后者会导致所有依赖重下，go run main.go 直接卡在下载阶段。
- 清理构建中间产物（安全）：
go clean -cache—— 清空$GOCACHE，不影响模块缓存 - 清理模糊测试缓存（顺手）：
go clean -fuzzcache - 清理模块缓存（谨慎）：
go clean -modcache—— 删除全部$GOPATH/pkg/mod，仅在 CI/CD 或确认缓存损坏时用 - 精准删某模块：
rm -rf $(go env GOMODCACHE)/github.com/sirupsen/logrus@v1.9.0 - 关掉 GoLand “Build project automatically”：Settings → Go → Build Tags & Vendoring → 取消勾选，避免保存即触发
go list往$GOCACHE写垃圾
项目打开后持续高 CPU、内存占用不降，检查是否在 init() 里干了不该干的事
GoLand 本身不执行你的 init()，但它会调用 go list -deps 和 gopls 分析依赖图——如果某个依赖包在 init() 中做了 I/O（比如读配置、连 DB、解析 YAML），gopls 就会在后台反复加载并卡死，表现为 CPU 持续 100%、IDE 响应迟钝。
- 快速定位重型
init()：go tool compile -S main.go | grep "CALL.*init"，看哪些包在初始化时调用了阻塞函数 - 典型雷区：
zap.NewProduction()（本地调试请换NewDevelopment()）、viper.ReadInConfig()、sql.Open()、http.Get() - 正确做法：把所有带 I/O 的操作挪到
main()开头，或用sync.Once包裹实现首次调用才初始化 - 别在
init()里调sync.Once.Do()——纯属冗余，init()本就是单次执行
init() 调用——这四点漏掉任一个，调再大内存都白搭。 
