dlv debug 启动失败找不到 main 包，主因是当前目录无 main.go 或 func main()、go.mod 模块名与路径不匹配；应切换至含 main.go 的正确目录或改用 dlv exec ./binary。
dlv debug 启动失败：找不到 main 包
直接运行 dlv debug 报错 could not launch process: could not find executable for 'main'，说明 Delve 构建阶段就失败了，不是调试器本身问题。
常见原因和应对方式：
- 当前目录下没有
main.go，或文件中缺失func main()；Delve 依赖 Go 的构建逻辑，必须能识别出可执行包 -
go.mod中的module名与当前路径不匹配（例如模块名是github.com/user/project/cmd/app，但你在project/根目录运行dlv debug）；应切换到cmd/app目录再试 - 项目在
vendor/目录下、或仍用 GOPATH 模式（无go.mod），dlv debug可能行为异常；改用dlv exec ./mybinary调试已编译二进制更稳妥
VS Code 中断点总停在 runtime 或 sync 包里
这不是配置错误，而是 Delve 默认加载标准库符号并启用内部断点（如 runtime.fatalthrow），导致调试时频繁跳进系统调用。
解决方法优先级从高到低：
- 在
.vscode/launch.json的配置中添加"dlvLoadConfig": { "skipInitialize": true }（仅 Delve v1.21+ 支持） - 调试启动后，在 VS Code 的「调试控制台」输入
config substitute-path /usr/local/go/src ""（macOS/Linux）或config substitute-path C:/Go/src ""（Windows），让源码映射失效 - 关闭 VS Code Go 插件设置里的
dlv: Show Global Variables，减少变量加载压力，间接缓解卡顿
远程调试时 dlv --headless 连不上
现象是本地客户端连上 :2345 后秒断，或提示 connection refused / EOF，本质是协议或权限未对齐。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
必须确认的三项：
- 服务端启动命令必须带
--api-version=2，VS Code 等 DAP 客户端默认只支持 v2 协议 - 若需多人同时连接（如团队共享调试环境），加
--accept-multiclient，否则第二个连接会被拒绝 - Linux 服务器上可能被
ptrace限制拦截，临时放开：echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
调试时变量显示为 <optimized out></optimized> 或无法查看
这是 Go 编译器优化导致的——变量被提升到寄存器、内联或死代码消除，Delve 读不到原始值。
构建时务必禁用优化：
- 调试用的二进制不能加
-ldflags="-s -w"（剥离符号和调试信息） - 必须传
-gcflags="-N -l"：-N禁用内联，-l禁用变量声明行号优化 - 推荐完整调试构建命令：
go build -gcflags="-N -l" -o myapp .，再用dlv exec ./myapp
真正容易被忽略的是：哪怕你用 VS Code 点击 F5 启动调试，它背后仍会调用 go build；如果项目根目录有 go.buildFlags 或 go.toolsEnvVars 配置覆盖了 -gcflags，照样会优化。检查这些配置项比反复重装 Delve 更有效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
