必须手动安装delve（dlv）并验证版本，配置launch.json中program和mode匹配启动方式，确保go.mod存在、PATH正确且禁用编译优化（-N -l）才能成功调试。
VS Code 调试 Go 代码前必须装对扩展和工具
不是装了 Go 扩展就能调试，delve（dlv）是 VS Code 调试 Go 的实际后端，它必须独立安装且版本与 Go SDK 兼容。常见错误是只装了 Go 扩展却没运行：
go install github.com/go-delve/delve/cmd/dlv@latest装完后在终端执行
dlv version 确认能输出版本号。如果提示 command not found，检查 $GOPATH/bin 或 $GOBIN 是否已加入 $PATH —— VS Code 默认不读取 shell 的 PATH，需在设置里配 "go.gopath" 或重启 VS Code 并用“Developer: Reload Window”刷新环境。
launch.json 中的 program 和 mode 必须匹配启动方式
断点不命中、调试器直接退出，八成是 launch.json 配置错。最常用的是调试单个 main 包：
{
"version": "0.2.0",
"configurations": [
{
"name": "Launch Package",
"type": "go",
"request": "launch",
"mode": "test", // ← 测单元测试用
"program": "${workspaceFolder}",
"env": {}
}
]
}注意：mode 值不是随意填的，常见取值有：
-
auto：自动判断（推荐新手） -
exec：调试已编译好的二进制（program指向 .exe 或可执行文件路径） -
test：跑go test，program应为包路径（如"./..."） -
exec或test下若program写成"${workspaceFolder}"但当前目录没有main.go或*_test.go，dlv 会静默失败
mode 是 auto 或 exec，且 program 指向含 func main() 的目录或已构建的二进制。
断点失效？检查 GOPROXY、vendor 和模块初始化状态
加了断点但灰色不可用（unverified breakpoint），不是 VS Code 抽风，而是 dlv 找不到源码映射。典型原因：
- 项目未初始化模块：
go mod init example.com/foo缺失 → dlv 无法解析 import 路径 - 用了
vendor但没开go build -mod=vendor→ dlv 加载的是 $GOROOT/src 下的标准库源码，而非 vendor 里的副本 - 设置了
GOPROXY=direct但网络不通，go mod download卡住 → dlv 启动时依赖模块下载完成，否则跳过源码关联 - 断点打在内联函数或编译器优化后的代码上（Go 1.19+ 默认开启
-gcflags="-l"可禁用内联，调试时建议加到args）
dlv debug --headless --api-version=2，看输出里是否有 could not find file 或 no source found for 类提示。
变量监视窗口看不到结构体字段或 map 内容
默认情况下，VS Code 的 Variables 面板只展开一层，深层字段、map 键值、slice 元素不会自动加载——这是性能保护，不是 bug。点击变量旁的 ▶ 手动展开即可；若展开后显示 [not accessible]，说明该变量已被编译器优化掉（比如未被后续代码使用），此时需在 go run 或 dlv debug 时加参数：
"args": ["-gcflags", "all=-N -l"]
-N 禁用优化，-l 禁用内联。注意：这会让二进制变大、运行变慢，仅调试时启用。另外，interface{} 类型变量在监视窗里默认只显示动态类型名，要看到底层值，得手动输入表达式如 myVar.(string) 或用 pp myVar（在 DEBUG CONSOLE 中）。
调试真正卡住的地方，往往不在配置文件，而在 GOPATH、模块路径和 dlv 启动时的工作目录三者是否一致。哪怕 launch.json 完全正确，如果终端里 cd 到错的目录再开 VS Code，或者用快捷方式打开工作区但没激活对应文件夹，dlv 就可能加载错包。每次怀疑调试异常，先在终端进项目根目录，手动跑一遍 dlv debug，看输出是否和 VS Code 里一致。 
