go 1.16+ 后 gopath 不再强制配置，仅影响 go install 输出路径；path 必须包含 go 的 bin 目录（如 /usr/local/go/bin），否则报 “command not found: go”；go111module=on 是关键，go mod init 的模块路径须与 import 路径严格一致。
Go 环境变量 PATH 和 GOPATH 还得设吗？
Go 1.16 之后，GOPATH 不再是强制要求；go mod 默认启用后，项目可脱离 GOPATH 目录结构。但 PATH 必须包含 Go 的 bin 目录（如 /usr/local/go/bin），否则终端无法识别 go 命令。
常见错误现象：command not found: go —— 90% 是 PATH 没配对；go: cannot find main module —— 多半是当前目录没 go.mod，和 GOPATH 无关。
- Linux/macOS：在
~/.bashrc或~/.zshrc中追加export PATH=$PATH:/usr/local/go/bin - Windows：通过「系统属性 → 高级 → 环境变量」添加
C:\Go\bin到用户或系统PATH - 验证命令：
go version和go env GOPATH（后者仅作参考，非必需）
go mod init 初始化失败的三个典型原因
go mod init 报错往往不是环境问题，而是当前路径或命名冲突导致的。它只负责生成 go.mod 文件，并不下载依赖。
常见错误现象：go: creating new go.mod: module path must be a valid module path —— 模块名含非法字符或以 . 开头；go: modules disabled by GO111MODULE=off —— 环境变量被手动关闭。
- 模块名建议用小写字母、数字、连字符，如
myapp或github.com/yourname/myapp，避免空格、下划线、大写 - 确保未设置
GO111MODULE=off；若设了，运行unset GO111MODULE（Linux/macOS）或set GO111MODULE=（Windows cmd） - 不要在已有
go.mod的父目录下重复执行，会报go: go.mod file already exists
go build 能直接跑起来，为什么还要搞部署脚本？
本地 go build 成功 ≠ 生产环境能跑。核心差异在目标平台、依赖注入和权限控制。
例如你在 macOS 上开发，但服务要部署到 Linux 服务器；又或者你用了 os/user.Current() 这类依赖系统用户的 API，在容器或无 home 目录的 systemd service 下会 panic。
- 跨平台编译必须显式指定：
GOOS=linux GOARCH=amd64 go build -o myapp main.go - 敏感配置（如数据库地址）别硬编码，改用
os.Getenv("DB_URL")，部署时通过Environment=注入到 systemd service 文件里 - 二进制文件需加执行权限：
chmod +x myapp，否则systemctl start会报Permission denied
vscode + gopls 配置卡在“Loading…”怎么办？
不是插件装少了，大概率是 gopls 启动时找不到模块根目录，或被代理/防火墙阻断了 module proxy 请求。
典型表现：代码补全失效、跳转定义灰色、状态栏一直显示 gopls: Loading…，但 go build 正常。
- 确认项目根目录有
go.mod，且 VS Code 是打开该目录（不是上级文件夹） - 临时关闭代理试试：
export GOPROXY=direct（Linux/macOS）或set GOPROXY=direct（Windows） - 重启 VS Code 后，按
Cmd+Shift+P（macOS）或Ctrl+Shift+P（Win/Linux），输入Developer: Toggle Developer Tools，看 Console 里是否有gopls连接超时日志
go mod download 可能因网络触发静默失败，后续所有依赖操作都看似正常，直到某天 go build 突然报 missing required module —— 那时候再查，已经混入了几十次无效的 go mod tidy。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
