需确认当前目录存在main.go且含func main()，检查go.mod模块名与路径匹配，子模块应cd至对应目录再执行dlv debug，避免在vendor或GOPATH旧项目中直接使用。
dlv debug 找不到 main 包怎么办
直接报 could not launch process: could not find executable for 'main'，说明 Delve 根本没构建出可执行文件。这不是 IDE 配置问题，而是项目结构或模块定义不满足 Go 构建前提。
- 确认当前目录下存在
main.go，且文件内有func main()—— 缺一不可；子命令项目（如cmd/myapp）必须cd cmd/myapp后再运行dlv debug - 检查
go.mod中的module名是否与当前路径匹配：比如模块名是github.com/user/project，但你在project/subdir下执行dlv debug，就会失败 - 避免在
vendor/目录或 GOPATH 模式旧项目中直接用dlv debug；更稳的方式是先go build -o myapp，再用dlv exec ./myapp
VS Code 调试总停在 runtime.gopark 怎么跳过
这不是断点设错了，是 Delve 默认加载了标准库源码映射，导致每次锁、协程调度、GC 都触发断点。你看到的“卡在 sync.Mutex.Lock”本质是调试器在帮你“看穿”框架底层，但多数时候你只想看自己的逻辑。
- 在
.vscode/launch.json的配置里加"skipInitialize": true（仅 Delve v1.21+ 有效），这是最干净的解法 - 若版本较旧，启动调试后，在调试控制台手动执行
config substitute-path /usr/local/go/src ""，让标准库路径映射失效 - 顺手关掉
dlv: Show Global Variables（VS Code 插件设置），能显著减少变量加载延迟，尤其在大型项目中
条件断点怎么写才真正生效
条件断点不是“写了就停”，它依赖两个硬性前提：变量必须在当前作用域内，且表达式语法必须是合法 Go 表达式。写错一个括号或类型不匹配，断点就静默失效。
- 循环中定位第 100 次迭代：
i == 100（i必须是当前函数内声明或传入的变量） - HTTP 请求中只停特定 path：
r.URL.Path == "/api/v1/users"（r是 *http.Request 类型，且该变量已初始化） - 避免写
len(data) > 0却没声明data，或误用=而非==；Delve 不报错，只是永远不触发 - 复杂条件建议拆成简单布尔表达式，比如
user != nil && user.ID > 0 && user.Status == "active"
远程调试连不上 dlv --headless
连接立刻断开或提示 connection refused，大概率是 API 版本不匹配或网络策略拦截，而不是端口没开。
立即学习“go语言免费学习笔记（深入）”；
- 必须加
--api-version=2：新版 VS Code / GoLand 默认只认 v2，漏掉这个参数，服务端会静默拒绝，客户端收不到明确错误 - 多调试器重连需开
--accept-multiclient，但它不等于支持并发 attach —— 第二个连接进来时，第一个会被踢出 - Docker 运行要显式暴露端口：
docker run -p 2345:2345 ...；K8s 则必须在 Pod spec 的ports和readinessProbe中同时配置，否则 probe 失败导致 Pod 无法 Ready，调试端口根本不可达
dlv stack 和 dlv goroutines 看到的堆栈可能跨多个文件、嵌套很深，这时候别急着单步，先用 dlv threads 确认哪些线程真正在运行，再结合 goroutine <id> bt</id> 定向查具体协程 —— 很多时候问题不在你写的 handler 里，而在中间件或日志 hook 的 defer 链中。 
