根本原因是ide的jvm内存耗尽触发高频gc，需调高-xms/-xmx、禁用g1gc、启用go.work支持、排除vendor目录、修复goproxy及replace配置。
GoLand代码分析器卡在 indexing… 怎么办
根本不是代码写得有问题，而是 IDE 的 JVM 堆内存被耗尽，触发高频 GC，导致分析器“假死”。现象是光标不动、文件打不开、右下角一直显示 indexing…，CPU 占满但无错误弹窗。
- 关闭 GoLand，编辑
goland.vmoptions文件（macOS 路径：~/Library/Caches/JetBrains/GoLand2023.3/goland64.vmoptions；Windows：%USERPROFILE%\AppData\Roaming\JetBrains\GoLand2023.3\goland64.vmoptions） - 把
-Xms和-Xmx改为-Xms2g和-Xmx4g（物理内存 ≤ 16GB 时适用；若 ≥ 32GB，可设为-Xmx6g，但别超 6g） - 加一行
-XX:ReservedCodeCacheSize=512m，避免 JIT 编译退化拖慢分析 - 删掉所有含
-XX:+UseG1GC的行——GoLand 官方明确不推荐手动改 GC 策略，G1 在中等堆下反而增加停顿
go.work 启用后分析器更慢甚至崩溃
GoLand 对 go.work 的支持从 2023.2 版本才真正稳定。旧版本或配置不当会导致 IDE 为每个 use 目录重复建 module，反复扫描相同依赖路径，索引量爆炸。
- 检查 Help → About，确认 build number ≥
232.9559.62；低于则升级 -
go.work文件里只保留必要路径，避免写成use ./module-a ./module-b ./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，尤其含大量测试文件时，效率骤降。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- Settings → Directories，将
vendor目录标记为Excluded（不是Source或Test） - 确保
go.mod中未启用replace指向vendor内路径——否则 IDE 仍会尝试解析 - 若项目必须依赖本地
vendor修改，改用go mod edit -replace指向外部路径，而非直接操作vendor
gopls 初始化慢导致补全/跳转卡顿
VSCode 里常见，但 GoLand 同样依赖 gopls 提供语义分析能力。首次打开大项目时，gopls 加载模块、解析依赖、构建缓存的过程会阻塞 UI，表现为补全延迟、跳转失败、loading… 悬浮提示。
- 确保已执行
go env -w GO111MODULE=on和go env -w GOPROXY=https://goproxy.cn,direct，否则gopls会卡在远程包验证 - 在 Settings → Go → Language Server 中，勾选
Use built-in gopls（新版 GoLand 自带较新gopls，比手动安装更稳） - 禁用
Enable code lens和Show documentation on hover（这两项在大型项目中会显著拖慢响应） - 如果只是临时调试单文件，可在 Settings → Editor → General → Auto Import 中关闭
Add unambiguous imports on the fly，减少gopls实时分析压力
关键点不在“怎么配”，而在于：JVM 参数调高后必须重启生效；vendor 排除后要手动触发一次“Reload project”；go.work 配置错误时，IDE 不会报错，只会默默低效运行——这些地方最容易被忽略。
