goland索引卡顿主因是jvm内存不足与模块解析策略不当；需调高-xms/-xmx至相同值（如2g）、禁用g1gc、启用go.work支持并排除vendor目录，四步可降70%+索引时间。
GoLand 索引卡顿不是项目问题，是 JVM 内存和模块解析策略没调对——调高堆内存、禁用 G1GC、启用 go.work 支持、排除 vendor，四步能压掉 70%+ 索引时间。
为什么-Xms/-Xmx必须手动调高
默认 JVM 堆（通常 750MB）在大型 Go 项目里几秒就耗尽，触发高频 GC，表现就是光标卡顿、索引进度条不动、文件打开延迟。这不是 Go 代码慢，是 IDE 自身内存不够用。
-
-Xms和-Xmx必须设为相同值（如-Xms2g和-Xmx2g），避免运行时动态扩容带来的 GC 震荡 - 不要超过物理内存的 50%，且
-Xmx不建议超 6g——JVM 超过这个阈值，GC 停顿反而陡增 - 加一行
-XX:ReservedCodeCacheSize=512m，防止 JIT 编译退化拖慢索引 - 删掉所有含
-XX:+UseG1GC的行——GoLand 官方明确不推荐手动改 GC 策略
go.work 支持必须显式开启且配置干净
旧版本或未正确启用 go.work 时，IDE 会为每个 use 目录单独建 module，重复扫描相同依赖路径，索引时间爆炸式增长。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 确认 GoLand 版本 ≥ 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，尤其当里面含大量测试或非 Go 资源时，效率极低。
- Settings → Directories → 选中
vendor目录 → 点击右上角Excluded - 检查 GOPROXY 配置是否生效：Settings → Go → GOPROXY 应设为
https://goproxy.io,direct，避免拉取私有包时 fallback 到本地 vendor 扫描 - 若用了
replace指向本地路径，确保该路径不在vendor内，否则仍会触发冗余扫描
最易被忽略的字符串开销：filepath.Clean 和 filepath.Abs
即使你已用 os.ReadDir 替代 filepath.Walk，如果在每层递归里都调 filepath.Clean 或反复 filepath.Abs，这些字符串操作在百万级条目下会吃掉可观 CPU——比任何并发优化都实在。
提前算好根路径并复用，例如在入口处调一次 filepath.Abs(root) 存为全局变量，后续所有拼接都用 filepath.Join(absRoot, name)，别在循环里反复计算。Windows 下尤其注意用 filepath.Join，不用 path.Join（它更重）。
