Go调试需确保dlv版本（github.com/go-delve/delve）、启动mode（exec/test）与IDE配置三者严格对齐，否则必现断点不命中或进程启动失败；务必用go install安装新版dlv，VS Code中显式设"mode":"exec"并指定绝对路径，GoLand需统一启用或禁用Go Modules。
Go 调试环境不是“配好就能用”，关键在 dlv 版本、启动方式和 IDE 插件三者对齐；用错任意一环，breakpoint not hit 或 could not launch process 就会反复出现。
确认 dlv 是 go-delve/dlv（非旧版 github.com/derekparker/dlv）
老教程常指向已归档的旧仓库，新版 VS Code Go 插件、GoLand 2023.3+、go test -exec dlv 均要求使用当前官方维护的 dlv。不匹配会导致调试器无法 attach、断点失效或 panic 在 proc.NewBinaryInfo。
- 执行
dlv version，输出应含Build ID: ... (github.com/go-delve/delve) - 若为
derekparker/dlv，先卸载：go uninstall github.com/derekparker/dlv/cmd/dlv@latest - 安装正确版本：
go install github.com/go-delve/delve/cmd/dlv@latest - 验证路径：
which dlv应指向$GOPATH/bin/dlv或$GOBIN/dlv，且与 IDE 中配置的dlvPath一致
VS Code 中 launch.json 的 mode 必须匹配运行场景
mode 决定 dlv 启动方式，选错会导致进程秒退或无法加载源码。它不是可选项，而是调试行为的底层开关。
-
"mode": "exec"：用于调试已编译的二进制（如go build -o main main.go后调试./main），需指定"program"为绝对路径 -
"mode": "auto"：VS Code 默认值，但实际行为不稳定——对单文件可能走exec，对 module 可能走test，易出错，建议显式指定 -
"mode": "exec"+"program": "${workspaceFolder}/main"是最可控组合；若用"mode": "exec"却没提前 build，会报could not launch process: fork/exec ... no such file or directory - 调试测试函数？必须用
"mode": "test"，且"args"中加-test.run=^TestXXX$，否则 dlv 不识别测试入口
GoLand 调试失败时优先检查 GOPATH 和 Go Modules 混用
GoLand 会自动推导 GOROOT 和 GOPATH，但若项目含 go.mod 且同时存在 GOPATH/src/xxx，dlv 可能从 GOPATH 加载依赖而非模块缓存，导致源码跳转错乱、变量显示
Vuex是一个专门为Vue.js应用设计的状态管理模型 + 库。它为应用内的所有组件提供集中式存储服务，其中的规则确保状态只能按预期方式变更。它可以与 Vue 官方开发工具扩展(devtools extension) 集成，提供高级特征，比如 零配置时空旅行般（基于时间轴）调试，以及状态快照 导出/导入。本文给大家带来Vuex参考手册，需要的朋友们可以过来看看！
立即学习“go语言免费学习笔记（深入）”；
- 关闭 GoLand 的
Go Modules Integration→Enable Go modules integration（即禁用该选项），强制走 GOPATH 模式（仅限老项目） - 新项目务必开启该选项，并确保
go env GOMOD返回非空路径，且dlv启动时工作目录为 module 根目录 - 若断点灰化，右键断点 →
Breakpoint Properties→ 取消勾选Ignore if source code is not available，再看是否提示source not found for ...—— 这说明 dlv 找不到对应 .go 文件，大概率是路径映射错位
调试时 goroutine 切换卡顿或看不到栈？关掉 subprocesses 和 follow-fork-mode
dlv 默认启用子进程跟踪（尤其在 exec 或 test 模式下），当程序调用 exec.Command 或启动子 goroutine 频繁时，调试器会同步抓取所有子进程状态，造成 UI 卡顿、堆栈展开延迟甚至崩溃。
- 在
launch.json中添加："dlvLoadConfig": { "followPointers": true, "maxVariableRecurse": 1, "maxArrayValues": 64, "maxStructFields": -1 }（这是基础配置，非解决卡顿主因） - 真正生效的是启动参数：在
launch.json的"dlvLoadConfig"外层加"dlvArgs": ["--only-same-user=false", "--headless=true"]，并确保未传入--continue或--accept-multiclient等干扰参数 - 更彻底的方式：改用
dlv debug命令行启动，手动控制goroutines列表刷新频率，比 IDE 自动轮询稳定得多
dlv 的调试行为高度依赖启动上下文，同一份代码，在 go run、go test、go build + exec 下触发的调试流程完全不同；不区分清楚就调，90% 的“断点不命中”其实根本不是环境问题，而是 mode 和 program 路径没对上。
