goland报“unresolved reference”但go build成功，说明非代码错误，而是ide索引或模块解析滞后；常见于切换分支、更新依赖或修改go.mod后未刷新，需检查go list -m all、go111module状态，执行synchronize或invalidate caches，并确认go modules启用、goproxy一致、go.work配置正确、大文件限制已调高、replace路径已手动映射。
GoLand 报“Unresolved reference”但 go build 成功
这不是代码问题，而是 GoLand 的索引或模块解析没跟上实际状态。常见于刚拉完新分支、切换 Go 版本、或本地依赖刚更新后 IDE 没及时刷新。
优先检查两件事：go list -m all 能否正常输出所有模块；go env GO111MODULE 是否为 on（不是 auto 或 off）。
- 右键项目根目录 → Synchronize，强制刷新文件系统视图
- 菜单栏 File → Invalidate Caches and Restart → Invalidate and Restart（尤其在改过
go.mod或代理配置后） - 确认 Settings → Go → Go Modules 中已勾选 Enable Go Modules，且
GOPROXY配置与终端一致（比如https://goproxy.cn,direct）
GoLand 识别不了 go.work 工作区里的跨模块引用
GoLand 对 go.work 的支持默认较弱，尤其当子模块未被显式标记为“Sources Root”时，IDE 无法自动推导 import 路径。
例如 module-a 定义了 util.PrintfGreen，module-b 在 go.work 中引用它，但 GoLand 报红——本质是它没把 module-a 当作可导入源。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 在 Project 视图中右键
module-a目录 → Mark Directory as → Sources Root - 确保
go.work文件位于项目根，并且内容格式正确（如go 1.20\nuse ( ./module-a ./module-b )） - 关闭 GoLand 的 “Use GOPATH that’s defined in System Environment” 选项（Settings → Go → GOPATH），避免 GOPATH 模式干扰模块路径解析
大文件导致 GoLand 停止索引，间接引发 import 报红
GoLand 默认对单个文件有大小限制（约 15MB），一旦 .go 文件超限，IDE 就跳过语法分析和符号索引，所有引用都变红，哪怕 go build 完全没问题。
典型场景：生成的 protobuf/gRPC stub 文件、内嵌大量 JSON/YAML 的常量文件、或日志模板拼接文件。
- Help → Edit Custom Properties → 添加两行：
idea.max.intellisense.filesize=999999idea.max.content.load.filesize=999999- 重启 GoLand 后生效（单位是 KB，即约 1GB 上限）
私有模块或 replace 路径在 IDE 中不生效
GoLand 不会自动读取 go.mod 里的 replace 指令，除非你手动告诉它“这个路径对应真实代码”。尤其在用 replace github.com/foo/bar => ../bar 开发本地模块时，IDE 往往只认远程路径。
- 打开 Settings → Go → Go Modules → 点击 Manage Replace Directives
- 添加对应条目：左边填原始模块路径（
github.com/foo/bar），右边填本地绝对路径（如/Users/me/dev/bar） - 或者更直接：右键本地模块目录 → Mark Directory as → Sources Root，再在
go.mod中保留replace，IDE 会优先索引本地路径
go build 是两套体系，报红≠不能跑。真正麻烦的是那种“部分报红+部分能跳转”的中间态——往往说明工作区配置、go.work 结构或 replace 映射没对齐，需要逐层验证路径是否被 IDE 实际纳入索引范围。
