根本原因是program路径未指向已编译的可执行文件；必须用go build生成二进制，program设为对应路径（windows需含.exe），并配合cwd、envfile等正确配置。
为什么 launch.json 里填了 program 还是报 “could not launch process”
根本原因通常是路径没对上——program 必须指向一个已编译好的可执行文件，而不是 .go 源文件。VS Code 的 Go 调试器（dlv）不支持直接调试源码，它需要二进制。
- 如果你用
go run main.go能跑通，但调试失败，大概率是program写成了"${workspaceFolder}/main.go"—— 这不对，得先go build出二进制，再把program指向它，比如"${workspaceFolder}/main" - Windows 下注意扩展名：
program值应为"${workspaceFolder}/main.exe"，漏掉.exe会静默失败 - 如果项目用了模块（
go mod init），且入口不在根目录，program路径必须和go build实际输出位置一致；建议统一在out/目录构建，避免污染源码树
用 dlv 调试时，env 和 envFile 哪个更可靠
envFile 更可控，尤其当环境变量含空格、换行或特殊字符时。env 字段是纯 JSON 对象，在 launch.json 里写多行或复杂值极易出错，而且无法复用已有 .env 文件。
-
envFile支持标准.env格式（KEY=VALUE），可被其他工具（如go run --env-file）共用 -
env中的变量会**完全覆盖**系统环境，包括GOPATH、GOROOT等；而envFile只加载你显式写的那些，更安全 - 如果必须用
env，避免在值里写$HOME或${PWD}—— VS Code 不解析 shell 变量，它们会被原样传给进程，导致路径错误
mode 设成 "exec" 还是 "auto"？什么时候必须手动指定
绝大多数情况用 "exec"，"auto" 容易误判——它会尝试根据 program 后缀判断模式，但 Go 二进制没有固定后缀（Linux/macOS 无扩展名，Windows 是 .exe），容易 fallback 到错误模式。
-
"exec"：明确告诉 dlv “这就是个已编译好的程序，直接运行”，稳定、可预测 -
"test"仅当你调试go test时才用，且需配合args: ["-test.run", "TestName"] - 如果你在
main.go同目录下有main_test.go，又没设mode，VS Code 可能自动选"test"并静默跳过断点——这是最常被忽略的坑
调试多模块项目时，cwd 和 args 怎么配才不踩路径坑
cwd 决定程序运行时的当前工作目录，直接影响相对路径读取（比如 os.Open("config.yaml")）；args 里的路径一律按 cwd 解析，不是按 launch.json 所在位置。
立即学习“go语言免费学习笔记（深入）”；
- 务必显式设置
cwd，不要依赖默认值；推荐设为"${workspaceFolder}"或具体子模块路径（如"${workspaceFolder}/cmd/myapp"） -
args中若含文件路径，写相对路径（如"./data/input.txt"），别写绝对路径——否则换机器就失效 - 如果程序依赖
go:embed，cwd必须设为包含go.mod的目录，否则 embed 资源找不到
调试 Go 程序真正卡住的地方，往往不是断点设不设，而是二进制在哪、当前目录在哪、环境变量从哪来——这三个点对不上，dlv 就连进程都起不来。