Go环境配置关键在GO111MODULE、GOPROXY和GOSUMDB三者：必须强制启用模块（go env -w GO111MODULE=on）、配置国内代理（go env -w GOPROXY=https://goproxy.cn,direct）、关闭或替换校验（go env -w GOSUMDB=off或sum.golang.google.cn），且项目须以go mod init初始化生成go.mod文件，否则依赖管理将失效。
Go 环境现在基本不用手动设 GOROOT 和 GOPATH，但盲目跳过配置环节，反而容易在 go run、go build 或依赖拉取时卡住——关键不是“要不要配”，而是“配什么、什么时候配、配错会怎样”。
go version 能跑 ≠ 环境就 ready
很多人执行 go version 成功就以为万事大吉，结果一跑 go mod init 就报 go: cannot find module providing package。这不是 Go 没装好，而是模块系统没激活或代理没通。
-
GO111MODULE默认已开启（Go 1.16+），但旧机器可能仍为auto，导致在非GOPATH目录下无法识别模块 —— 执行go env -w GO111MODULE=on强制启用 -
GOPROXY必须设，尤其在国内：不设就会卡在golang.org/x/...类包上 —— 推荐go env -w GOPROXY=https://goproxy.cn,direct -
GOSUMDB建议同步关闭校验（或换国内镜像）：否则go get可能因 checksum 失败中断 ——go env -w GOSUMDB=off或go env -w GOSUMDB=sum.golang.google.cn
项目目录可以放 anywhere，但 go.mod 是唯一权威
你完全可以在 ~/projects/myapi 或 /tmp/test 下直接初始化项目，不需要塞进 $GOPATH/src/xxx。但一旦 go.mod 文件存在，所有路径解析、依赖下载、构建行为都以此为根。
- 新建项目第一件事就是
go mod init example.com/myapp（域名/占位符均可，不必真实存在） - 如果已有代码但没
go.mod，go build会退化为 GOPATH 模式，且无法正确解析相对导入 —— 别跳过go mod init -
go.sum不该手动改，它由go mod tidy自动生成并锁定校验和；删了它再跑tidy会重拉所有依赖
PATH 里只加 $GOROOT/bin，别硬塞 $GOPATH/bin
从 Go 1.10 开始，GOROOT 可自动推导，只要 $PATH 包含 $GOROOT/bin（即 go 命令所在目录），其余工具如 gofmt、go vet 都能直接调用。而 $GOPATH/bin 只用于存放 go install 安装的 CLI 工具（比如 gopls、dlv），不是必须加入 PATH 的。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 检查是否多余：运行
which go和which gopls，若后者报错但go install golang.org/x/tools/gopls@latest成功，说明$GOPATH/bin没进PATH—— 此时才需补加 - Windows 用户注意：
%GOPATH%\bin和%GOROOT%\bin都要进系统 PATH，但顺序无关紧要 - VS Code 的 Go 插件会读取 shell 的
PATH，所以改完.zshrc后务必重启编辑器，否则插件找不到gopls
go env 输出比文档更可信
所有环境变量最终以 go env 显示为准，而不是你 ~/.zshrc 里写的那行 export。很多问题其实只是 reload shell 失败，或不同 shell（bash/zsh/fish）配置不一致。
- 每次怀疑配置失效，先跑
go env | grep -E '^(GO|GOPROXY|GOSUMDB)'看真实值 -
go env -w写的是$HOME/go/env文件，优先级高于 shell 环境变量 —— 如果你用export GOPROXY=...和go env -w GOPROXY=...同时存在，以后者为准 - CI/CD 环境中不要依赖用户 shell 配置，应显式用
go env -w设置，避免因基础镜像差异导致构建失败
真正容易被忽略的，是 go env -w 的持久化机制和 go.mod 初始化时机——前者让配置脱离 shell 上下文，后者决定了整个项目的模块边界。这两步做错，后续所有依赖、测试、构建都会偏离预期，但错误信息往往不直接指向根源。
