Go代码中不能直接写breakpoint，必须依赖delve调试器设置断点；VS Code点击行号或dlv命令行用b命令添加，runtime.Breakpoint()仅实验性且功能受限。
Go 代码里不能直接写 breakpoint，得靠调试器
Go 本身没有像 Python 的 breakpoint() 那样的内置断点函数（直到 Go 1.22 才实验性加入 runtime.Breakpoint()，但不推荐日常用）。你写的 main.go 或任何 .go 文件里，不能靠插入某行代码来“加断点”——必须启动调试会话，由调试器在指定位置暂停执行。
实际开发中，99% 的断点是通过 IDE（如 VS Code + dlv）或命令行 dlv 设置的。核心依赖的是 delve（dlv），不是 Go 自带的 go tool pprof 或 go test -debug。
VS Code 里点行号左边加断点，背后其实是 dlv 的 break 命令
你在 VS Code 的 main.go 第 12 行左侧灰色区域单击，出现红点，这动作会触发 VS Code 调用 dlv 的 break 命令，类似：
dlv debug --headless --listen=:2345 --api-version=2
然后 VS Code 通过 DAP 协议发请求：{"command":"setBreakpoints","arguments":{"source":{"name":"main.go","path":"/path/to/main.go"},"breakpoints":[{"line":12}]}}。
立即学习“go语言免费学习笔记（深入）”；
所以关键不是“怎么写”，而是“怎么配”：
- 确保已安装
dlv：go install github.com/go-delve/delve/cmd/dlv@latest - VS Code 安装官方扩展
Go（由 golang.org/x/tools 提供支持） - 项目根目录有
go.mod，且GO111MODULE=on（否则dlv可能找不到依赖） - 不要在
init()函数第一行设断点——dlv启动时可能尚未加载该包，断点会显示为 pending（灰点），需等包初始化完成才生效
dlv 命令行调试时，用 b 或 break 加断点最可靠
不用 IDE？直接跑 dlv debug 进交互式调试器，加断点就两条命令：
-
b main.main：在main.main函数入口设断点（注意是main.main，不是main()） -
b ./main.go:15：在当前目录下main.go第 15 行设断点（路径必须准确，相对路径以dlv启动目录为基准） -
b mypkg.MyFunc：在其他包的导出函数设断点，前提是该包已 build 进二进制（非go run模式） - 错误示例：
b MyFunc（没包名）→ 报错could not find function；b main.go:15（缺./）→ 可能匹配不到文件
加完用 bp 查看所有断点，用 c 继续执行，n 单步（next），s 进入函数（step）。
Go 1.22 的 runtime.Breakpoint() 是个陷阱，别在生产逻辑里用
Go 1.22 引入了 runtime.Breakpoint()，调用后会让程序在该处暂停——但它只在调试器附加时生效；没连 dlv 时，它什么也不做（不是 panic，也不是 sleep，就是静默跳过）。
这意味着：
- 它不能替代
dlv断点，因为无法控制条件、命中次数、日志输出等 - 如果误写在循环里又忘了删，上线后毫无效果，但代码污染已存在
- 它不支持条件断点（比如
if x > 100才停），而dlv支持：b main.go:20 condition "x>100" - 交叉编译（如
GOOS=linux go build）后，再用dlv调试本地 macOS 二进制会失败；但runtime.Breakpoint()在那种场景下也完全无效
真正要“动态插桩”，应该用 log.Printf + runtime.Caller，或者上 pprof / trace，而不是指望运行时断点。
