Delve调试失败主因是启动方式或构建参数错误：dlv debug仅调试main包，测试须用dlv test；断点需写完整包路径如github.com/myorg/myproj/pkg.TestFoo；必须加-gcflags="-N -l"禁用优化；VS Code中program字段应填包路径而非文件路径。
Delve 不是“装上就能断点”的工具，它对编译方式、包路径、执行入口极其敏感——调试失败八成不是 Delve 问题，而是启动方式或构建参数错了。
dlv debug 和 dlv test 完全不兼容
你写了 func TestFoo(t *testing.T)，在 pkg/foo_test.go 里打了断点，执行 dlv debug 却完全不触发？这是最典型的误用。
-
dlv debug只编译并调试main包，压根不会加载任何_test二进制 - 测试代码被
go test编译为独立的myproj/pkg.test文件，必须用dlv test启动 - 想只跑一个测试：用
dlv test -- -test.run ^TestFoo$（注意双横线--是必需分隔符） - 当前目录必须是待测包路径，比如
myproj/pkg/，不是项目根目录或cmd/
断点必须写完整包路径，不能省略模块名
Delve 不识别裸函数名。你在 pkg/foo_test.go 里写的 TestFoo，实际全名取决于 go.mod 里的模块声明。
- 查真实包名：运行
go list -f '{{.ImportPath}}' ./pkg，输出类似github.com/myorg/myproj/pkg - 设断点必须写
break github.com/myorg/myproj/pkg.TestFoo，写break pkg.TestFoo或break TestFoo都会悬空 - 行号断点可临时用：
break pkg/foo_test.go:42，但首次建议优先用全名确保命中 - VS Code 中断点没生效？看调试控制台是否打印
Breakpoint 1 set at …，没这句就是路径错
-gcflags="-N -l" 不是可选项，是调试前提
变量显示
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
-N禁用所有优化，-l忽略内联 —— 两个缺一不可 - 命令行调试：所有
dlv命令后加-gcflags="-N -l"，例如dlv test -gcflags="-N -l" -- -test.run ^TestFoo$ - VS Code：
launch.json的args字段里明确加两项："-gcflags"和"-N -l"（顺序不能反） - 别担心体积和性能：这是调试阶段的必要代价，上线构建时自然去掉
VS Code 的 program 字段填的是包路径，不是文件路径
很多人把 "program": "./main.go" 或 "program": "." 当成“指定入口”，结果断点全悬空，控制台报模糊错误如 could not launch process: stub exited while waiting for connection。
- 单模块项目，
main.go在根目录："program": "${workspaceFolder}" - 多模块，
main在cmd/myapp："program": "${workspaceFolder}/cmd/myapp" - 这个字段本质是告诉 Delve “去哪找
main包”，不是“读哪个文件” - 如果项目用了 Go Workspaces，确保当前打开的文件夹是 workspace root，否则
go list找不到包
真正卡住人的从来不是 Delve 功能少，而是它对 Go 构建模型的严格遵循——包路径、编译标志、测试二进制隔离，每一步都得对得上，漏一个就静默失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
