GoLand定位Bug需让其“现形”：看滚动条红点查静态错误；运行测试通过Problems窗口分析堆栈；打断点用F8单步观察变量；检查日志是否含文件行号；并发等问题需-race、Delve等辅助排查。

GoLand 本身不运行代码，所以“有 Bug 的代码”不会自动高亮——它只靠静态分析、运行时日志、测试失败和调试器来暴露问题。定位关键不在“找 Bug”，而在“让 Bug 现形”。下面几种方式按实际使用频率和有效性排列。

看编辑器右侧滚动条上的红色标记

这是最直接的线索：GoLand 持续做静态检查，只要检测到语法错误、未使用的变量、类型不匹配、nil 指针风险等，就会在滚动条对应行位置标红点或黄点。

• 鼠标悬停在标记上，立刻显示问题描述，比如 nil pointer dereference possible 或 func is unused
• 点击标记，光标跳转到具体行；按 Alt Enter 可看到修复建议（如添加 nil 检查、删除未用变量）
• 注意：某些检查默认关闭（比如竞态检测），需手动启用——进 Settings → Editor → Inspections 搜索关键词启用

跑测试并点开“问题”工具窗口

测试失败是 Bug 最可靠的信号源。GoLand 把测试输出结构化呈现，比终端日志更易定位。

GoLand 2026.1.1

GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。

下载

• 右键测试函数 → Run 'TestXXX'，失败后自动弹出 Problems 工具窗口（或按 Alt 0 6 手动打开）
• 左侧列表里点某条失败项，右侧显示完整堆栈；关键不是最后一行，而是倒数第三、四行——那里通常是你的业务代码调用点
• 如果堆栈里只有 runtime. 或 testing. 开头的帧，说明 panic 发生在测试内部（比如 goroutine panic 未被捕获），需加 recover 或用 -race 复现

打断点 + F8 单步进调试

当 Bug 表现为逻辑错（值不对、分支走错、状态没更新），静态检查和测试堆栈都帮不上忙，必须进执行流看现场。

• 在疑似出问题的行号左侧边距点击设断点（红点），按 F9 启动调试（或右键 → Debug 'main'）
• 进入后用 F8 逐行执行，注意观察 Variables 面板里变量值变化；尤其关注 map/slice 的 len/cap、指针是否为 nil、channel 是否已关闭
• 别依赖“跳入”（F7）进标准库或第三方包——多数时候只需看输入输出是否符合预期；真要进，先确认那行是不是你 own 的逻辑入口

查日志里带 main.go:42 这类位置信息的错误

Go 默认 error 不带堆栈，但日志可以补上。如果你的日志输出里只有 "json: cannot unmarshal" 而没有文件行号，说明 log.SetFlags() 没生效或被覆盖了。

• 检查是否在 init() 或 main() 最开头调用了 log.SetFlags(log.Lshortfile | log.LstdFlags)
• 避免混用多个日志库（如 zap + std log），它们的配置互不影响；统一用 log 时，确保所有 log.Print* 都发生在 flag 设置之后
• 若用 golangci-lint，它也能报告可疑日志调用（比如漏掉 log.Printf 的格式参数），这类警告常指向真实 Bug 温床

真正难定位的 Bug 往往藏在并发、延迟初始化、外部依赖（时间、文件、网络）或隐式接口实现里——这些地方静态检查几乎失灵，得靠 -race、打日志、加 defer fmt.Printf 或用 Delve 的 goroutine list 手动排查。别指望 IDE 自动圈出所有问题，它只负责把线索摆到你面前。