dlv attach 失败因 ptrace 权限限制，需调整 kernel.yama.ptrace_scope 或为 dlv 设置 cap_sys_ptrace；断点未命中多因源码路径不匹配或二进制被 strip；break 不支持通配符，须用 funcs 查函数名后精确设置；CPU 占高属正常调试开销，应避免条件断点和长时间停顿。
dlv attach 时提示 “could not attach to pid: operation not permitted”
Linux 默认禁止非 root 用户 attach 到其他进程，这是 ptrace 权限限制导致的。Go 程序用 dlv attach 调试时若遇到这个错误，不是 dlv 安装问题，而是系统策略卡住了。
- 临时解决：启动目标程序前加
sudo sysctl -w kernel.yama.ptrace_scope=0（仅当前会话生效） - 永久方案：把
kernel.yama.ptrace_scope = 0写进/etc/sysctl.d/10-ptrace.conf，再执行sudo sysctl --system - 更安全的做法是只对调试用户开放能力：用
sudo setcap cap_sys_ptrace+ep $(readlink -f $(which dlv))，避免降级整个系统的 ptrace 保护
在 main.main() 开头设断点却没命中
dlv 的断点解析依赖源码路径和编译信息。如果 Go 程序是交叉编译、或用 go build -trimpath 打包、或运行在容器里但源码没挂载进去，dlv 就找不到 main.main 对应的源码行。
- 确认调试时用的是未 strip 的二进制：构建时别加
-ldflags="-s -w" - 检查 dlv 启动路径是否在项目根目录（或包含
go.mod的目录），否则break main.main可能解析失败 - 用
dlv exec ./myapp --headless --api-version=2启动后，先执行sources看 dlv 能识别哪些文件路径；若显示空或路径错乱，说明源码映射已丢失 - 容器内调试务必挂载源码目录，且确保路径与本地开发环境一致（比如都用
/app）
dlv 的 break 命令不支持通配符或模糊匹配
想给所有 HTTP handler 设断点？别试 break *handler 或 break .*/handler.go —— dlv 的 break 不支持正则或通配，它只认具体函数名、文件名:行号、或符号名。
- 查可用函数：启动 dlv 后输入
funcs ^http.*Serve（注意是^开头的正则，不是通配） - 按行设断点最稳：比如
break server.go:42，比猜函数名靠谱 - 想拦截所有 handler 调用，可以 break 在
net/http.serverHandler.ServeHTTP，这是实际分发入口（注意函数名大小写和包路径） - 用
bp（简写）查看当前断点列表，避免重复设置或漏掉已失效的断点
dlv debug 进程 CPU 占用飙升到 100%
这不是 bug，是 dlv 在持续轮询 goroutine 状态、捕获信号、维护调试上下文导致的。尤其当程序有大量 goroutine 或高频 timer 时，开销更明显。
立即学习“go语言免费学习笔记（深入）”；
- 关掉不必要的调试功能：启动时加
--only-same-user=false（默认 true）反而可能降低干扰，但要配合set follow-fork-mode child控制子进程跟踪 - 避免在 hot path 上设条件断点（如
break main.go:100 if x > 1000），每次执行都得求值，拖慢整个进程 - 调试完及时
continue，别让程序停在断点上太久；用step单步时留意 goroutine 切换，容易误入 runtime 调度逻辑 - 生产环境慎用 dlv attach，优先考虑 pprof + 日志定位，dlv 更适合开发机或 staging 环境
断点位置和源码路径的对应关系，比想象中更脆弱；一次 go mod vendor 或换个 GOPATH 都可能让断点“消失”。调试前花 30 秒确认 dlv version 和 go version 兼容性，比卡住一小时更有用。
