根本原因是goland的jvm内存分配不合理，需调高-xms/-xmx、禁用g1gc、启用go.work支持、排除vendor目录、修复goproxy及replace配置。
GoLand 启动后内存飙升、卡顿，根本不是代码问题
绝大多数人以为是自己写的 Go 程序吃内存，其实 GoLand 本身 JVM 堆配置太小，一开多项目或 vendor 多就频繁 GC，表现就是编辑卡、索引挂起、CPU 占满但无报错。物理内存 16G 的机器，-Xmx 设成 2g 就已经明显不够用了。
-
-Xms和-Xmx必须成对调高，比如设为-Xms2g和-Xmx4g；-Xmx不建议超6g，否则 GC 压力反而陡增 - 删掉所有含
-XX:+UseG1GC的行——GoLand 官方明确不推荐手动改 GC 策略，G1 在中等堆场景下停顿更多 - 加一行
-XX:ReservedCodeCacheSize=512m，避免 JIT 编译退化拖慢索引和代码补全 - Windows 路径：
%USERPROFILE%\AppData\Roaming\JetBrains\GoLand2023.3\goland64.vmoptions；macOS：~/Library/Caches/JetBrains/GoLand2023.3/goland64.vmoptions
开了多个 Goland 实例后内存错乱？先关掉“Show Memory Indicator”
这个功能本身不耗资源，但它会持续轮询 JVM 内存状态，多个实例同时跑时容易触发竞态，显示的内存占用数值跳变、不准，甚至干扰 GC 判断。它只是个指示器，不是监控工具。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 双击
Shift→ 输入Show Memory Indicator→ 取消勾选（不是禁用插件） - 真正要查内存，用 Activity Monitor（macOS）或任务管理器（Windows）看
goland64进程 RSS 即可 - 如果必须开多个实例，建议每个实例单独配
vmoptions文件，并把-Xmx总和控制在物理内存 40% 以内
vendor 目录被反复扫描，索引时间翻倍
Goland 默认把 vendor 当普通源码目录，每次改一个 .go 文件，就会触发整个 vendor 的增量 re-index。尤其当里面混着测试文件、.md 或 .proto，效率直接崩盘。
- Settings → Directories → 选中
vendor目录 → 点右上角Excluded（不是 “Sources”） - 确认 GOPROXY 配置正确（如
https://proxy.golang.org,direct），避免 IDE 回退到本地 vendor 查找依赖 - 检查
go.mod中是否有残留的replace指向本地路径，这会让 Goland 误判为需索引的模块
go.work 支持没开稳，索引变慢甚至失败
GoLand 对 go.work 的支持从 2023.2 才稳定。旧版本或未关闭自动探测，IDE 会为每个 use 目录建独立 module，重复扫描相同依赖路径，索引爆炸。
- Help → About → 确认 build number ≥
232.9559.62，否则升级 - Settings → Go → Modules → 勾选
Enable Go workspaces support，**取消勾选Auto-detect modules** - 删掉
.idea/modules.xml和.idea/misc.xml，重启后让 IDE 重新按go.work构建 module 关系 -
go.work文件里不要写use ./module-a ./module-a/internal这类嵌套路径，internal会被重复解析
vendor 没 exclude、go.work 没配对、多个实例共享同一份 vmoptions，内存占用就永远压不下来。最有效的优化，往往藏在配置开关里，而不是数字大小上。
