根本原因是JVM内存配置不合理，需修改goland64.vmoptions：设-Xms2g/-Xmx4g、加-XX:ReservedCodeCacheSize=512m、删掉-XX:+UseG1GC，并排除vendor目录、启用go.work支持且禁用Auto-detect modules。
GoLand代码提示卡顿，根本不是gopls或Go代码本身的问题，而是IDE底层JVM堆内存和编译缓存配置不合理——尤其在开启go.work或多模块项目时，goland64.vmoptions里默认的1G堆内存几秒就耗尽，触发频繁GC，直接拖垮索引和补全响应。
怎么改goland64.vmoptions让提示变快
关掉GoLand，找到对应系统的goland64.vmoptions文件（macOS在~/Library/Caches/JetBrains/GoLand2023.3/goland64.vmoptions，Windows在%USERPROFILE%\AppData\Roaming\JetBrains\GoLand2023.3\goland64.vmoptions），按以下顺序调整：
-
-Xms2g和-Xmx4g：初始和最大堆设为2GB/4GB，别超物理内存50%，也别设-Xmx6g以上——JVM堆太大反而GC停顿更长 -
-XX:ReservedCodeCacheSize=512m：加这一行，否则JIT编译缓存不足，gopls调用路径反复退化成解释执行，补全延迟翻倍 - 删掉所有
-XX:+UseG1GC：Goland官方明确不推荐手动指定GC策略，G1在4–6G堆下反而增加STW时间，留空让JVM自动选ZGC或Parallel - 确保没有
-Didea.is.internal=true这类调试参数——它们会关闭部分优化路径
为什么启用go.work后提示更慢了
GoLand 2023.2之前对go.work支持不完整，旧版本会把每个use目录当成独立module重复扫描，导致相同vendor包被解析3–5次，补全候选集构建爆炸。
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里只写顶层模块路径，别包含./api/internal这种子目录——IDE会把它当新module再建一次索引 - Settings → Go → Modules中勾选
Enable Go workspaces support，并**取消勾选Auto-detect modules**——否则仍走旧逻辑扫描 - 删掉
.idea/modules.xml和.idea/misc.xml，重启强制重建module关系
vendor目录怎么避免拖慢补全
GoLand默认把vendor/当普通源码目录，每次敲fmt.都会重新扫描整个vendor里的fmt包结构，尤其含大量测试文件时，补全延迟从200ms拉到2s+。
- Settings → Directories → 右键
vendor目录 → Mark as Excluded - 如果项目必须依赖vendor内私有修改，用
replace指向本地路径，而不是把vendor留在源码树里 - 检查
go.mod是否含冗余replace——每个replace都会让go list多扫一次路径，直接影响补全前的符号解析耗时
最常被忽略的是：改完vmoptions必须彻底退出GoLand（macOS要右键Dock图标→Quit，不能只关窗口），否则JVM不会重载参数；另外，补全延迟高时先看Event Log里有没有“Indexing paused due to low memory”，有就说明堆还是不够——这时候调-Xmx比调任何Go代码都管用。
