专业go环境需装好go命令、设go111module=on、避开gopath/src路径；path未生效会导致go version报错；go mod init失败常因目录在gopath/src下、存在vendor/或go111module=off；gopls依赖go可用、有go.mod且文件在合规路径；国内须配goproxy=https://goproxy.cn,direct。
装好 go 命令、配对 GO111MODULE=on、避开 GOPATH/src 路径，这三件事做对了，环境就算搭得专业。其余所谓“IDE 配置”“插件堆砌”都是锦上添花，不是基础。
验证 go 命令是否真可用
很多人执行 go version 报 command not found，不是没装，是 PATH 没生效。
- macOS/Linux：运行
which go，有输出才说明终端认得到；没有就检查/usr/local/go/bin或安装路径是否写进~/.zshrc（或~/.bash_profile），然后source ~/.zshrc - Windows：用 PowerShell 运行
Get-Command go，失败就去「系统属性 → 高级 → 环境变量」里确认C:\Program Files\Go\bin是否在 PATH 中 - 别信安装器勾选的“添加到 PATH”——它只改注册表或 shell 配置文件，不自动重载；关掉再打开终端，或手动
source才算数
go mod init 失败的常见诱因
新建项目时 go mod init myapp 无声失败或生成错误 module 名，大概率卡在这几个地方：
- 当前目录在
$GOPATH/src下：go mod init会试图按旧 GOPATH 规则推导 module 名，比如变成myproject而不是你想要的myapp；切到任意非GOPATH/src目录再试 - 项目里还留着
vendor/目录：模块模式下vendor/是可选的，但存在时可能干扰初始化；删掉再跑 -
GO111MODULE被设为off：执行go env -w GO111MODULE=on强制启用（Go 1.16+ 默认开启，但 CI 脚本或老终端可能关着）
VS Code 里 gopls 启动失败的硬性条件
gopls 不是装了插件就自动工作，它依赖三个底层事实成立：
-
go命令必须全局可用（which go有结果） - 项目根目录下要有
go.mod（哪怕只是空文件，go mod init生成的就行） - 打开的文件后缀是
.go，且不在vendor/或GOPATH/src下——否则gopls会拒绝服务
如果 gopls 日志报 no modules found，先检查是不是漏了 go.mod；报 not in a module，说明路径不对或模块未启用。
国内用户绕不开的 GOPROXY 配置
不配代理，go get 或 go mod download 很可能卡死或超时，这不是网络问题，是直连 proxy.golang.org 在国内不可达。
- 推荐命令：
go env -w GOPROXY=https://goproxy.cn,direct -
direct表示对私有仓库（如公司内网 Git）走直连，避免代理误转发 - 验证是否生效：
go env GOPROXY应输出https://goproxy.cn,direct - 注意：这个设置只影响当前用户，不同用户需各自运行一次
真正容易被忽略的是路径判断和模块启用时机——go mod init 不是“点一下就完事”的操作，它对当前目录位置、环境变量状态、已有文件结构都敏感。很多“环境搭好了但项目跑不起来”的问题，根源都在初始化那一秒没踩对节奏。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
