根本原因是jvm堆内存设过高（如-xmx8g）引发gc压力陡增，尤其g1gc在中等项目下停顿拉长；应设-xms2g/-xmx2g避免动态伸缩，删useg1gc行、加-xx:reservedcodecachesize=512m，并按物理内存合理限高（16gb机≤4g）。
GoLand 启动卡在 indexing，不是代码问题，是 IDE 自身 JVM 配置 + 项目结构不匹配导致的资源耗尽。
为什么调高 -Xmx 反而更卡？
堆内存设太高（比如 -Xmx8g）会触发 JVM 的 GC 压力陡增，尤其在中等规模 Go 项目（含 vendor 或多模块）下，G1GC 默认启用时停顿时间反而拉长。GoLand 官方明确不推荐手动指定 GC 策略。
- 把
-Xms和-Xmx设为相同值（如-Xms2g -Xmx2g），避免堆动态伸缩带来的 GC 频次上升 - 删掉所有含
-XX:+UseG1GC的行——Goland 2023.2+ 已默认适配 ZGC，强行改 G1 是倒退 - 加一行
-XX:ReservedCodeCacheSize=512m，否则 JIT 编译退化会拖慢符号解析速度 - 物理内存 16GB 机器，
-Xmx别超 4g；32GB 机器上限建议 6g，再高收益断崖下跌
go.work 启用后索引变慢甚至失败
旧版 Goland（use 目录单独建 module，重复扫描相同依赖路径，索引量指数级膨胀。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 确认版本 ≥ 2023.2（Help → About → Build number ≥ 232.9559.62）
-
go.work文件里避免写use ./module-a ./module-a/internal这类嵌套路径，internal 子目录会被二次解析 - Settings → Go → Modules → 勾选
Enable Go workspaces support，并取消Auto-detect modules - 删掉
.idea/modules.xml和.idea/misc.xml，重启让 IDE 从go.work重建 module 关系
vendor 目录被反复扫描，索引时间翻倍
GoLand 默认把 vendor 当普通源码目录，每次保存任意 .go 文件都会触发对整个 vendor 的增量 re-index，尤其当里面混有测试文件、.md、.proto 等非 Go 资源时，效率极低。
- Settings → Directories → 选中
vendor目录 → 点右上角 “Excluded” 按钮（变成红色图标） - 确保 GOPROXY 配置正确（如
https://goproxy.cn），避免 IDE 在索引时 fallback 到慢速网络 fetch - 检查
go.mod里有没有冗余replace指向本地路径，这类路径若不存在或权限异常，会阻塞模块解析线程
最易被忽略的是：索引卡顿往往不是单一原因，而是 go.work 配置错误 + vendor 未排除 + JVM 参数不合理三者叠加。先停掉所有后台检查（Settings → Languages & Frameworks → Go → 取消勾选 Enable Go modules integration），确认是否真快了，再逐项打开验证。否则改了参数却还在等 gopls 扫描完，根本测不出效果。
