根本原因是JVM堆内存不足和GC策略错配，需调高-Xms/-Xmx、禁用G1GC、启用go.work支持、排除vendor目录、修复GOPROXY及replace配置。
Goland 索引卡顿、CPU 占满、光标响应迟滞，基本不是 Go 代码或项目本身的问题，而是 IDE 的 JVM 配置和模块解析逻辑没对齐当前项目结构。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
为什么 Goland 启动后卡在 indexing…
根本原因是 JVM 堆内存不足 + GC 策略错配，尤其在含 go.work 或大量 vendor 的项目中，IDE 会反复扫描相同路径，触发高频 Full GC。
- 常见现象：CPU 持续 90%+、Indexing… 状态长期不消失、打开新文件明显延迟、Go to Definition 失效
- 不是 Go 编译慢，也不是 GOPROXY 慢——即使关掉所有 Go 插件，JVM 进程仍吃满 CPU
- 关键线索：Activity Monitor（macOS）或任务管理器里看到多个 jetbrains-goland 进程，其中一个是 java 主进程，RSS 内存持续上涨后陡降（GC 循环）
Goland 的 goland.vmoptions 怎么调才有效
直接改配置文件比在 Settings 里调更可靠，且必须重启生效。
- 找到对应路径：
- macOS：~/Library/Caches/JetBrains/GoLand2023.3/goland64.vmoptions
- Windows：%USERPROFILE%\AppData\Roaming\JetBrains\GoLand2023.3\goland64.vmoptions
- Linux：~/.config/JetBrains/GoLand2023.3/goland64.vmoptions
- 必改三行（其他默认值可保留）：
- -Xms2g（初始堆，别设太低）
- -Xmx4g（最大堆，不超过物理内存 50%，且不建议 >6g）
- -XX:ReservedCodeCacheSize=512m（避免 JIT 编译退化拖慢索引）
- 必删一行：-XX:+UseG1GC（Goland 官方明确不推荐，G1 在 2–4g 堆下反而增加 STW 时间）
启用 go.work 后反而更慢？怎么修复
go.work 支持从 GoLand 2023.2（build ≥ 232.9559.62）才真正稳定，旧版本会把每个 use 目录当独立 module 扫描。
- 检查版本：Help → About 里看 build number，低于 232.9559.62 建议升级
- go.work 文件内容要干净：
- ✅ 正确：use ./backend ./frontend
- ❌ 错误：use ./backend ./backend/internal ./frontend（internal 子目录会被重复解析）
- Settings → Go → Modules 中：
- 勾选 Enable Go workspaces support
- 取消勾选 Auto-detect modules（否则 IDE 仍按旧逻辑遍历子目录）
- 删除 .idea/modules.xml 和 .idea/misc.xml，重启让 IDE 重建 module 关系
vendor 目录被反复扫描怎么办
Goland 默认把 vendor 当作源码目录，每次保存一个 .go 文件就触发全量 vendor 增量索引，尤其含测试文件时极慢。
- 最有效办法：在 Settings → Directories 中，右键 vendor 目录 → Mark as Excluded
- 补充检查：GOPROXY 是否设为 direct 或私有代理？若 replace 指向本地路径但未被 go.work 覆盖，IDE 可能误判依赖关系，导致重复加载
- 注意：vendor 排除后，跳转定义会受限——这是 trade-off，但索引速度提升通常值得
真正卡住的点往往不在代码里，而在 IDE 如何理解你的项目结构。改完 vmoptions 和 go.work 配置后，一定要删掉 .idea 下的缓存文件再重启，否则旧索引状态会残留。
