Go 1.16+ 不需配置 GOPATH，GOROOT 通常也无需手动设置；关键要确保 GO111MODULE=on、GOPATH 不与 GOROOT 混淆、$GOPATH/bin 在 PATH 中，且 dlv/gopls 等工具安装路径和版本与当前 Go 匹配。
检查 GOPATH 和 GOROOT 是否被错误覆盖
Go 1.16+ 默认启用模块模式（GO111MODULE=on），但很多旧脚本或 CI 配置仍硬编码 GOPATH，导致 go install 写入非预期路径，后续 dlv 或 gopls 找不到二进制。常见现象是 VS Code 报错 "dlv not found"，即使已执行 go install github.com/go-delve/delve/cmd/dlv@latest。
- 运行
go env GOPATH GOROOT GO111MODULE，确认GOPATH不是空或/usr/local/go（那是GOROOT的典型值） - 若
GO111MODULE显示auto，且项目根目录无go.mod，Go 会退化为 GOPATH 模式——此时go get仍可用，但行为不可控 - CI 中应显式设
GO111MODULE=on，避免依赖环境默认值
dlv 版本与 Go 运行时不匹配
Delve 调试器必须与当前 Go 版本 ABI 兼容。用 go install 安装的 dlv 若来自旧 commit（如 @latest 指向 v1.21.0），而本地 Go 是 1.23.x，可能触发 "could not launch process: fork/exec ... no such file or directory" 或断点失效。
- 不要用
go install github.com/go-delve/delve/cmd/dlv@latest—— 改为指定兼容版本：go install github.com/go-delve/delve/cmd/dlv@v1.23.0（与 Go 小版本号对齐） - 验证：运行
dlv version，输出中Build arch应与go version -m $(which dlv)一致 - VS Code 的
launch.json中可加"dlvLoadConfig"避免加载过深嵌套结构，减少调试卡顿
Go extension 自动安装工具链失败却静默忽略
VS Code 的 Go 扩展在首次打开项目时会提示安装 gopls、goimports 等工具，但若网络受限或权限不足（如公司代理拦截），它可能跳过安装或装到用户家目录外的临时位置，导致格式化、跳转、补全全部失灵，而 UI 无报错提示。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 手动触发安装：按
Cmd/Ctrl+Shift+P→ 输入Go: Install/Update Tools→ 全选并执行 - 检查是否真装上：
which gopls goimports，二者输出路径应一致（通常为$GOPATH/bin） - 若
gopls启动失败，看日志：Go: Toggle Log，常见原因是GOROOT指向一个没装src的精简版 Go（如某些 Linux 发行版包管理器提供）
多 Go 版本共存时 go 命令指向不明
开发者常通过 asdf、gvm 或手动解压多个 Go 版本，但 PATH 顺序混乱会导致 go version 与 dlv 编译时链接的 Go 运行时不一致，表现为调试时 panic 信息错乱、runtime/debug.ReadStack 返回空等底层异常。
立即学习“go语言免费学习笔记（深入）”；
- 查实际调用链：
readlink -f $(which go)和readelf -d $(which dlv) | grep RUNPATH - VS Code 调试时，
launch.json可显式指定"goRuntimePath"，避免依赖PATH查找 - 团队内统一用
goenv或.tool-versions固定版本，比靠文档约定更可靠
go mod tidy 成功但 go test 报 import cycle，本质是 GOPATH 残留干扰了模块解析；又比如 dlv 能启动却无法读取变量，其实是 gopls 加载了错误版本的分析缓存。这些都需要交叉验证而非单点检查。 
