dlv test是调试Go测试的唯一正确入口，因dlv debug仅运行main包；断点需用完整包路径如myproj/pkg.TestFoo；变量显示<optimized out>须加-gcflags="-N -l"禁用优化。
dlv 不是“装了就能用”的调试器，很多卡点根本不在操作步骤里，而在 Go 编译模型和调试上下文的错配上。直接上手就断不进、变量为空、断点悬空——这些问题有明确归因，不是配置玄学。
dlv test 才是调试测试的唯一入口
写好 TestFoo，加了断点，执行 dlv debug 却完全不触发？因为 dlv debug 只构建并运行 main 包，而测试代码被编译进独立的 *_test 二进制，跟 main 毫无关系。
-
dlv test：启动当前包所有测试，进入 REPL 后再手动设断点、用c运行 -
dlv test -- -test.run ^TestFoo$：只构建并运行单个测试，--是硬性分隔符，漏掉会导致-test.run被当成dlv参数而静默失效 - 必须在含
go.mod的包根目录下执行，否则报no Go files in directory - 查准确包名最快方式：
go list -f '{{.ImportPath}}' ./
断点必须带完整包路径，不能只写函数名
Delve 不识别裸函数名。你在 pkg/foo_test.go 里写的 TestFoo，实际全名是 myproj/pkg.TestFoo（取决于 go.mod 的模块名和目录结构）。
- 错误写法：
break TestFoo、break pkg.TestFoo—— 断点悬空，控制台无提示 - 正确写法：
break myproj/pkg.TestFoo或break pkg/foo_test.go:42（后者适合快速定位，但首次建议用全名确保命中） - VS Code 中看调试控制台是否打印
Breakpoint 1 set at …，没这句说明路径错
变量显示 <optimized out>？必须加 -gcflags="-N -l"
这不是 Delve 的 bug，是 Go 编译器默认做了内联和寄存器优化，把变量从栈帧里“删”了。Delve 没法读取不存在的东西。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 命令行调试时，所有
dlv命令后都得追加：dlv test -gcflags="-N -l" -- -test.run ^TestFoo$ - VS Code 的
launch.json中，在args字段里加两项："-gcflags"和"-N -l"（顺序不能反） -
-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" - 调试测试：
"mode": "test"，同时program仍指向包路径（如"${workspaceFolder}/pkg"），不是_test.go文件
复杂点在于：Go 的构建上下文（main vs test）、编译器优化行为（-N -l）、Delve 的符号解析逻辑（包路径匹配）三者耦合紧密。任何一个环节错位，调试就变成“看起来在跑，实则没进”。最常被忽略的是 -gcflags 和 program 字段语义——它们不是可选项，而是调试能成立的前提。
