VS Code 提示 dlv command not found 主因是 PATH 未生效，需重启 VS Code；program 字段须填明确包路径或 .go 文件；断点失效多因编译优化或 -s/-w 参数剥离调试信息。
dlv command not found 是 PATH 没生效，不是没装
VS Code 提示 dlv command not found，90% 是 dlv 二进制在系统里，但 VS Code 启动时没读到它。VS Code 只在启动瞬间加载一次 PATH，改完环境变量不重启编辑器，就永远找不到 dlv。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 终端运行
which dlv（macOS/Linux）或where dlv（Windows），确认路径是否真实存在 - 如果输出为空，说明没装或装错位置；如果有输出，比如
/Users/xxx/go/bin/dlv，那就把它加进系统PATH - macOS/Linux：检查
~/.zshrc或~/.bash_profile是否含export PATH="$GOPATH/bin:$PATH"；Windows：确认%GOPATH%\bin已加入「系统环境变量」而非仅当前终端 - 改完必须彻底退出 VS Code（不是关窗口，是右上角 × 关进程），再重新打开
program 字段填错直接报 fork/exec no such file or directory
launch.json 里的 program 不是填编译产物路径，也不是填 . 或 ./ 这种模糊写法——Delve 会直接失败，报 could not launch process: fork/exec no such file or directory。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 单文件项目（
main.go在根目录）：填"${workspaceFolder}/main.go" - 多包项目（如
cmd/myapp/main.go）：填"${workspaceFolder}/cmd/myapp"，即入口包路径，不是文件路径 - 必须确保该路径下有
main函数且能被go build正常识别；若项目用了 Go Modules，go.mod必须在${workspaceFolder}根目录 - 别写
"./"或"."——Delve 不解析相对路径通配符，只认明确的包路径或 .go 文件
断点不命中，大概率是编译优化或构建 tag 干扰
断点打了却跳过，不是代码问题，而是 Delve 编译时生成的调试信息和实际执行代码不一致。常见于默认开启的编译优化、CGO 启用、或用了 //go:build tag 的场景。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在
launch.json的args中强制禁用优化："args": ["-gcflags", "-N -l"] - 如果项目用了构建 tag（如
//go:build linux），调试时需显式传入："args": ["-tags", "linux"] - CGO_ENABLED=0 时调试行为可能异常，除非真需要纯静态链接，否则保持
CGO_ENABLED=1 - 避免用
go build -ldflags="-s -w"打包后调试——-s剥离符号表，-w剥离 DWARF 调试信息，Delve 就完全抓不到源码映射
远程调试必须用 --headless + --listen，且端口不能暴露在公网
本地调试靠 dlv debug 启动交互式会话，远程调试必须走无界面模式，否则连不上。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 服务器上启动命令固定为：
dlv debug --headless --listen=:2345 --api-version=2 -
--listen绑定地址建议用127.0.0.1:2345，而非:2345；若需跨机访问，务必配合 SSH 隧道：ssh -L 2345:localhost:2345 user@server - 本地
launch.json改用"mode": "connect"，并设"port": 2345和"host": "127.0.0.1" - 千万别把
--listen=:2345直接开在公网 IP 上——Delve 没认证机制，等于把整个进程内存裸奔暴露
-s -w 这两个 flag，一加进去，断点就成摆设，但错误提示里根本不会提——它只会安静地跳过。 
