条件断点适用于只关注特定状态而非每次执行都中断的场景，如HTTP路径匹配、循环特定索引、错误类型过滤等，用于精准调试且避免污染代码。
条件断点该在什么场景下用
当你不想每次循环、每个请求或每条数据都中断，只关心特定状态时，就必须用条件断点。比如：HTTP handler 里只对 req.URL.Path == "/api/users/123" 停；for 循环中只在 i == 999 时暂停；或者只在 err != nil 且 err.Error() == "timeout" 时介入。
它不是用来替代日志的，而是代替你手动加 if debug { debugger.Break() } 这种临时代码——避免污染逻辑，也不用反复编译重启。
- 高频调用函数中排查某次异常输入
- goroutine 泄漏时定位特定 ID 的 goroutine 启动点
- map/slice 操作前检查 key 是否存在、len 是否超阈值
- 避免在调试时被健康检查、心跳请求打断
Condition 输入框里能写什么、不能写什么
GoLand 在断点行「执行前」求值，表达式必须是当前栈帧内可静态访问的 Go 布尔表达式。写错不会报错，但断点静默失效——它直接跳过。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- ✅ 可用：
id > 100、user.Name == "admin"、len(data) == 0、req.Header.Get("X-Trace-ID") != "" - ❌ 禁止：
fmt.Println("hit")（含副作用）、items[0]（非布尔、可能 panic）、unknownVar == 1（变量未声明或作用域外） - ⚠️ 危险：
m["key"] == "val"必须先判空 → 改成m != nil && m["key"] == "val"；u.Email.String()若u.Email是 nil，整个条件求值失败，断点跳过
配置条件断点的实操要点
右键行号旁的红色断点标记 → 选 Edit Breakpoint… → 勾选 Condition 输入框，敲入单行表达式。别换行，GoLand 不支持多行条件。
- 快捷键更高效：
Ctrl+Shift+F8（Windows/Linux）或Cmd+Shift+F8（macOS）直接呼出配置面板 - 修改后无需重启调试会话，下次命中断点即生效
- 若用 dlv CLI 调试，确保 dlv 版本 ≥
v1.21+，旧版对复杂条件支持不稳定 - goroutine 中设条件断点时，默认只在当前 goroutine 求值，无法跨 goroutine 访问变量
为什么断点没停住？优先查这三处
最常踩的坑不是语法错，而是作用域、求值时机和 nil 访问。比如你在 i++ 那行设断点，条件写 i == 5 是对的；但若断点设在下一行，此时 i 已经是 6，条件自然不成立。
- 确认变量是否在当前栈帧可见（比如闭包变量、函数参数、局部变量）
- 检查结构体或指针是否已初始化，
user != nil && user.ID == 123比user.ID == 123安全得多 - 远程调试或容器内调试时，确保源码路径与二进制编译时一致，否则变量名解析失败，条件无法求值
条件断点的威力不在“能写多复杂”，而在“写得足够窄、足够安全”。越早意识到它是在断点行执行前做一次轻量布尔判断，就越少掉进静默跳过的陷阱。
