根本原因是dlv找不到go命令或GOPATH/GOROOT配置错误；需检查which go和go env GOPATH GOROOT是否返回有效路径，常见于Docker/CI未装go、版本管理工具未重载环境、GOROOT设错等场景。
dlv debug 报错“could not launch process: fork/exec … no such file or directory”
这是最常见的启动失败，根本原因不是 dlv 本身坏了，而是它找不到 go 命令或当前环境没配好 GOPATH/GOROOT。Delve 启动调试目标时，会调用 go build 先编译成二进制再调试，如果 go 不在 $PATH 里，或者 GOBIN 指向了不存在的目录，就会卡在这一步。
检查方法很简单：which go 和 go env GOPATH GOROOT 必须都返回有效路径。常见坑包括：
- 在 Docker 容器或 CI 环境中只装了
dlv二进制，没装go编译器 - 用
asdf或gvm切换 Go 版本后，shell 未重载配置，dlv继承的是旧 shell 环境 -
GOROOT被手动设错（比如指向/usr/local/go/src而不是/usr/local/go）
dlv test 调试时提示“no test files found”或跳过断点
Delve 的 dlv test 不是直接跑 go test，它会先尝试构建测试包，再注入调试逻辑。如果当前目录下没有以 _test.go 结尾的文件，或测试函数不满足 func TestXxx(*testing.T) 签名，就会静默失败。
更隐蔽的问题是：测试文件被 //go:build 或 // +build 条件编译排除了，但 dlv test 默认不读取这些约束——它只看文件名和函数名。实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先手动运行
go test -v确认测试能跑通 - 确保调试命令在正确的模块根目录执行（即含
go.mod的目录），否则dlv可能无法解析导入路径 - 想调试特定测试函数，用
dlv test -- -test.run=TestFoo，注意双横杠后的参数会透传给go test，不是dlv自己的 flag
vscode-go 插件连不上 dlv-dap，日志报“connection refused”
这不是插件问题，而是 dlv-dap 进程根本没起来，或者端口被占。VS Code 的 dlv-dap 默认监听 localhost:2345，但它不会自动拉起服务——你得先手动跑 dlv dap --listen=:2345，再点 “Start Debugging”。很多人误以为点绿色三角就能全自动，结果连不上。
另一个高频原因是：VS Code 工作区开了多个 Go 项目，但 launch.json 里 dlvLoadConfig 或 dlvDapPath 配错了路径，导致插件试图调用一个不存在的 dlv-dap 二进制。验证方式：
- 终端执行
dlv dap --version，确认输出版本号且无报错 - 检查
launch.json中dlvDapPath是否指向绝对路径（如/home/user/go/bin/dlv-dap），而非相对路径或空值 - 如果用 remote debug，
listen不能写127.0.0.1:2345，得改成:2345才能接受外部连接
加了断点但程序运行不停，或者停在 runtime/xxx.go 里
断点失效通常因为源码路径和编译时路径不一致。Delve 依赖调试信息里的 file:line 映射，而 Go 编译器默认把绝对路径写进 DWARF 数据。如果你在容器里编译、宿主机上调试，或者用了 go run main.go 这种临时编译方式，路径对不上，断点就挂空挡。
解决的关键是统一构建环境，并显式控制调试信息：
- 避免用
go run调试，改用go build -gcflags="all=-N -l" -o myapp . && dlv exec ./myapp（-N -l关闭优化和内联） - 跨环境调试时，在编译机上用
go build -trimpath -ldflags="-buildid="，减少路径残留 - 如果断点总停在
runtime/proc.go这类系统文件，大概率是没在用户代码里成功下断——检查是否在main()之前就触发了 panic 或 init 函数，这时候需要在runtime.main或runtime.goexit下硬件断点辅助定位
路径映射和构建上下文，才是 Delve 调试里最不声不响又最要命的环节。
