Go命令找不到是因shell未加载新PATH，需source配置文件或重启终端；go mod init需指定模块名；VS Code需手动安装gopls；go build异常多因模块模式或CGO设置不一致。
Go 安装后 go 命令找不到？PATH 没配对
不是安装失败，是 shell 没加载新 PATH。macOS/Linux 下改了 ~/.zshrc 或 ~/.bash_profile 后，得手动执行 source ~/.zshrc；Windows 则必须重启终端（CMD/PowerShell/WSL 都算），光开新窗口不够——环境变量不会自动继承。
验证方式很简单：echo $PATH（macOS/Linux）或 echo %PATH%（Windows），确认输出里包含 Go 的安装路径，比如 /usr/local/go/bin 或 C:\Program Files\Go\bin。
- Mac M1/M2 用户容易误装 Intel 版 Go，导致
go version报错或卡住，优先用brew install go - Windows 用户若用 Chocolatey 安装，别漏掉
refreshenv命令，否则 PATH 不生效 - WSL 中安装 Go 后，VS Code 连 WSL 时需确保 Remote-WSL 插件已启用，否则
go命令在编辑器内仍不可用
go mod init 报错 “cannot determine module path” 怎么办
这是 GOPATH 时代遗留的惯性操作：在非模块化项目里直接运行 go mod init，但没指定模块名。Go 1.13+ 默认开启模块模式，go mod init 必须带参数，比如 go mod init example.com/myapp。
模块名不强制要求是真实域名，但影响后续 go get 行为和 IDE 识别。本地开发可填任意合法包路径（如 myproj），只要不和标准库、已知第三方重名即可。
立即学习“go语言免费学习笔记（深入）”；
- 当前目录下已有
go.mod文件时，再执行go mod init会报错，删掉旧文件或用go mod edit -module 新名字修改 - 如果项目路径含空格或中文，
go mod init可能静默失败，建议先切到纯英文路径 - CI 环境中未设
GO111MODULE=on，会导致go build降级走 GOPATH 模式，间接让go mod相关命令失效
VS Code 里写 Go 提示“no workspace”或无法跳转定义
不是插件没装，是没正确启用 Go 扩展的 Language Server（gopls）。VS Code 的 Go 插件默认依赖 gopls，但它不会自动下载——首次打开 .go 文件时，右下角会弹提示，点 “Install” 才真正拉取二进制。
如果跳过提示或网络受限，gopls 就一直缺位。此时所有智能提示、格式化、引用查找都会失效，但语法高亮和基础 lint 还在，容易误判为“功能正常”。
- 手动触发安装：按
Cmd+Shift+P（macOS）或Ctrl+Shift+P（Windows/Linux），输 “Go: Install/Update Tools”，勾选gopls后执行 - 检查是否启用：打开设置搜 “go use language server”，确认
Go: Use Language Server是勾选状态 - gopls 启动慢？删掉
~/.cache/gopls（macOS/Linux）或%LOCALAPPDATA%\gopls（Windows）可重置缓存
为什么 go run main.go 能跑，但 go build 出来的二进制一运行就 panic
常见原因是本地依赖版本不一致。比如 go run 用的是 go.mod 锁定的版本，而 go build 若在 GOPATH 下执行、或环境变量 GO111MODULE=off，就会绕过模块系统，去 GOPATH/src 找包，结果用了老版本甚至不同实现。
另一个隐蔽原因是 CGO。某些包（如 net、os/user）在 CGO_ENABLED=0 时行为不同，而 go run 默认开启 CGO，go build 在交叉编译或容器中可能被关闭。
- 统一用
go build -mod=readonly强制走模块模式，避免意外降级 - 查构建环境：运行
go env CGO_ENABLED和go env GO111MODULE，确认两者值与预期一致 - 交叉编译时加
CGO_ENABLED=0是为了生成纯静态二进制，但代价是部分标准库功能受限（比如 DNS 解析走纯 Go 实现，可能不兼容某些企业内网配置）
go env 输出，比反复重装更省时间。 
