调试Go测试必须用dlv test而非dlv debug，因其专构_test二进制；需加-gcflags="-N -l"禁优化和内联；VS Code中program填包路径而非文件路径；条件断点与观察点可大幅提升效率。
直接用 dlv debug 调试测试函数？不行，断点根本不会命中——dlv debug 只编译 main 包，而测试代码在独立的 *_test 二进制里。
调试测试必须用 dlv test，不是 dlv debug
你写了 func TestFoo(t *testing.T)，加了断点，执行 dlv debug 却毫无反应，这是最常卡住的第一步。
-
dlv test是调试 Go 测试的唯一入口：它会构建并启动测试专用二进制，加载所有_test.go文件 - 日常推荐写法：
dlv test -- -test.run ^TestFoo$（注意--分隔符不能漏，否则-test.run会被当成dlv参数静默忽略） - 必须在含
go.mod的包根目录下执行，比如你的测试在pkg/目录，就cd pkg再运行，而不是项目根目录或cmd/ - 断点要用完整包路径：
break myproj/pkg.TestFoo，不是break TestFoo或break pkg.TestFoo；查包名最快方式是go list -f '{{.ImportPath}}' ./
变量显示 <optimized out>？必须加 -gcflags="-N -l"
这不是 Delve 读不到，是 Go 编译器把变量优化掉了——内联 + 寄存器分配后，变量根本没落栈，Delve 没东西可读。
- 命令行调试时，所有
dlv命令后都得追加：-gcflags="-N -l"，例如dlv test -gcflags="-N -l" -- -test.run ^TestFoo$ - VS Code 中，在
launch.json的args字段里加两项："-gcflags"和"-N -l"（顺序不能反） -
-N禁用优化，-l忽略内联——两个缺一不可；少了任一个，locals或p x都可能为空 - 加了之后二进制稍大、运行略慢，但这是调试阶段的必要代价；上线构建时去掉即可
VS Code 断点不命中？检查 program 字段填的是包路径，不是文件路径
很多人把 "program": "./main.go" 或 "program": "." 当成“指定入口文件”，结果断点全悬空，控制台只报模糊错误如 could not launch process: stub exited while waiting for connection。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
program字段表示“要调试哪个 Go 包”，不是“去跑哪个文件” - 单模块项目、
main.go在根目录："program": "${workspaceFolder}" - 多模块、
main在cmd/myapp："program": "${workspaceFolder}/cmd/myapp" - 调试测试时：
"mode": "test"，同时program仍指向包路径（如"${workspaceFolder}/pkg"），不是foo_test.go文件
条件断点和观察点能省掉 80% 的手动单步
在循环里反复 n 到第 100 次才出问题？不如让 Delve 自动帮你跳过。
- 设普通断点后加条件：
cond 1 len(items) > 50（ID 为 1 的断点只在条件为 true 时暂停） - 按命中次数设断点：
cond-hitcount == 100，适合定位循环中特定迭代的问题 - 监控变量变化用
watch items[0].Name，只要这个字段被修改，程序立刻中断，不用猜在哪赋的值 - 观察点对指针内容也有效：
watch *ptr，即使ptr地址不变，只要它指向的内存变了就会触发
真正容易被忽略的是：远程调试必须配 --headless --api-version=2，且 VS Code 的 launch.json 里 apiVersion 必须显式写成 2；用错版本号会导致连接成功但断点全部失效，现象和路径错误一模一样，极难排查。
