go version报错说明go未正确加入path或安装未完成，根本原因是shell找不到go可执行文件；macos/linux需手动将/usr/local/go/bin加入~/.zshrc并source，windows需确认安装时勾选“add go to path”或手动配置系统环境变量。
go version 命令报错或不识别，说明什么
说明 go 未正确加入系统 PATH，或者安装根本没完成。这不是“环境变量没配全”的问题，而是最基础的可执行文件找不到。
常见现象：command not found: go（macOS/Linux）、'go' 不是内部或外部命令（Windows）。
- Windows 用户检查安装时是否勾选了「Add Go to PATH」——新版 .msi 安装器默认勾选，但手动取消过就会失效
- macOS 使用 .pkg 安装后，
/usr/local/go/bin必须在 shell 配置文件（如~/.zshrc）里显式追加到PATH，仅靠安装器不一定生效 - Linux 手动解压后，
/usr/local/go/bin必须写进~/.bashrc或~/.zshrc，且要运行source ~/.zshrc生效 - 别用
which go判断——它可能返回旧版本残留路径；直接用go version测试才可靠
go run 和 go build 的区别在哪
go run 是临时编译并立即执行，不生成可执行文件；go build 编译出二进制文件，可分发、复用、调试。
两者对目录结构和参数敏感度完全不同：
-
go run main.go：只接受单个.go文件，且该文件必须属于main包，不能带其他依赖文件（除非全列出来） -
go run .：运行当前目录下整个main包，自动识别所有.go文件，推荐日常开发使用 -
go build默认生成同名可执行文件（如main），加-o可指定输出名：go build -o ./bin/app . -
go build不会自动运行，也不检查main包外的代码逻辑错误（比如 import 未使用），而go run会做完整检查
为什么 go mod init 后 go run 还报 missing required module
因为 go run 在模块模式下，会严格按 go.mod 中声明的依赖版本去解析 import 路径。如果代码里写了 import "golang.org/x/sys"，但 go.mod 里没这行，就会报错。
这不是网络问题，也不是 GOPATH 残留，而是模块感知机制在起作用：
- 首次运行前，先执行
go mod tidy—— 它会自动补全缺失依赖、清理未使用项 - 国内用户必须设代理，否则
golang.org域名无法解析：go env -w GOPROXY=https://goproxy.cn,direct - 不要手动编辑
go.mod添加 replace 或 exclude，除非你清楚后果；go mod edit是安全操作入口 - 如果项目里有
vendor/目录，go run默认忽略它，除非加-mod=vendor
VS Code 里点运行按钮没反应，怎么快速定位
不是插件没装，而是 VS Code 的 Go 插件默认依赖 dlv（Delve 调试器）——它不在 Go 安装包里，必须单独下载。
现象：点击 ▶️ 图标无输出、终端空、状态栏显示 “Starting debug session…” 卡住。
- 打开 VS Code 终端，运行
go install github.com/go-delve/delve/cmd/dlv@latest（注意是go install，不是go get） - 确认
$GOPATH/bin（或$GOBIN）在系统PATH中，否则 VS Code 找不到dlv - VS Code 设置里搜
go.toolsManagement.autoUpdate，设为true，下次打开项目会自动拉取缺失工具 - 别用
dlv dap手动启动——那是底层协议，VS Code 插件自己会调用，手动干预反而破坏流程
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
