条件断点需用合法go表达式，变量必须在当前作用域存在且拼写准确；禁止方法调用、函数调用和高开销操作；推荐使用简单布尔组合与runtime.goid()过滤协程。
GoLand 的条件断点不是“设了就能用”，它依赖 Delve 表达式引擎，只认当前栈帧里真实存在的变量、只支持有限的 Go 语法、且每次命中都会求值——写错或写重，轻则不触发，重则卡死调试器。
条件断点必须用原生 Go 表达式，不能写字符串或 JSON
常见错误是把条件写成 "user.ID == 'abc123'"（带双引号），结果断点从不触发。GoLand 的 Condition 字段解析的是 Go 代码，不是模板字符串。
-
user.ID == "abc123"✅ 正确：字符串字面量用双引号，符合 Go 语法 -
"user.ID == 'abc123'"❌ 错误：整个是字符串字面量，Delve 不会解析其内容 -
user.Status === "active"❌ 错误：Go 没有===，只认==
变量必须在当前作用域真实存在，拼写和大小写一个都不能错
断点设在 for i := range items 循环内，条件写 i == 42 没问题；但若写成 idx == 42 或 I == 42，Delve 静默忽略，断点退化为无条件触发。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 检查变量是否在当前行已声明且未超出作用域（比如不在
if块内声明却在块外设断点） - 结构体字段要逐层访问：
req.Header.Get("X-Trace-ID")❌ 不支持方法调用；req.Header["X-Trace-ID"]✅ 可用（但需确保req.Header非 nil） - 避免空安全操作符：
user.Profile?.Active❌ 不支持；user.Profile != nil && user.Profile.Active✅ 安全
别在条件里调用函数、做 IO 或高开销操作
条件表达式会在每次执行到该行时求值。一次 json.Marshal(req) 可能耗时几十毫秒，在 HTTP handler 里会导致调试严重卡顿，甚至掩盖真实性能瓶颈。
- 禁止：
http.Get("...")、os.ReadFile(...)、time.Now()、len(someSlice) > 0 && someSlice[0] == x（若someSlice可能 panic） - 推荐：
req.ID == "abc123"、len(data) > 10、m != nil && m["key"] != nil - 复杂逻辑提前计算：在断点前一行写
valid := isValid(req)，条件里只写valid
并发场景下，用 runtime.GoID() 过滤 goroutine
GoLand 没有“线程断点”，只有 goroutine-aware 断点。想让断点只在某个协程中生效，靠的是 runtime.GoID() 条件过滤。
- 先在代码里打印 ID：
log.Printf("goroutine ID: %d", runtime.GoID()) - 断点右键 → Edit Breakpoint → 勾选 Condition，填入
runtime.GoID() == 123 - 慎用
strings.Contains(debug.Stack(), "...")：堆栈捕获开销大，仅作临时排查 - 配合 Debugger 面板顶部的
Goroutines标签页，实时观察哪些 goroutine 处于 Running / Waiting 状态
最易被忽略的一点：条件断点里的表达式一旦 panic（比如访问 nil map 或越界 slice），整个调试会中断，GoLand 可能卡住或崩溃——这不是 IDE bug，而是 Delve 的行为限制。务必对所有可能为 nil 的值做前置判断。
