go环境搭建关键在于goroot、gopath与模块模式协同：go111module必须为on，goroot需手动配置（尤其windows自定义路径），go mod init模块名须匹配未来托管地址，且需同步配置goproxy与gosumdb。
Go 环境搭建不是“装完就完事”，关键在于 GOROOT、GOPATH 和模块模式的协同是否干净——否则后续 go mod 报错、依赖拉不下来、IDE 无法识别包，全是它埋的雷。
go version 能跑 ≠ 环境就绪
很多人执行 go version 成功后就以为万事大吉，但实际项目一跑 go run main.go 就报 cannot find module providing package fmt 或 no required module provides package。这不是 Go 没装好，而是当前目录没在模块上下文里，或 GOPATH 干扰了模块发现逻辑。
- 新版 Go（1.16+）默认启用模块模式（
GO111MODULE=on），不再依赖GOPATH/src目录结构 - 若仍手动设置了
GOPATH且未初始化go.mod，Go 会尝试 fallback 到旧模式，导致路径解析混乱 - 验证方式：运行
go env GO111MODULE，输出必须是on；再执行go mod download std不报错才算基础通路正常
Windows 下 .msi 安装后 Path 配置常漏掉这一项
Windows 用户双击 go1.xx.x.windows-amd64.msi 后，安装程序通常自动把 %GOROOT%\bin 加进系统 Path，但很多人忽略：如果自定义安装路径（比如 D:\Go），GOROOT 环境变量不会被自动创建，而某些 IDE（如 GoLand）或 CI 脚本会显式读取它。
- 手动添加系统变量
GOROOT，值设为你的安装根目录（如D:\Go），不是D:\Go\bin - 检查
Path中是否同时存在%GOROOT%\bin和%GOPATH%\bin——后者仅用于存放go install生成的可执行文件，非必需 - 重启终端或 CMD 再运行
go env GOROOT，确认输出与你设置一致
go mod init 的模块名不能随便写
新建项目时执行 go mod init myproject 看似无害，但模块名会成为所有导入路径的根前缀。一旦将来要推送到 GitHub，又想用 github.com/username/myproject 引入，就会因模块名不匹配导致 import 解析失败、vendor 失效、甚至测试覆盖率工具误判。
- 模块名应与代码未来托管地址一致，例如：项目准备放
https://github.com/yourname/api，就该用go mod init github.com/yourname/api - 模块名中不能含空格、中文、下划线开头，推荐全小写 + 连字符（
my-api） - 如果已初始化错误，可删掉
go.mod和go.sum，再用正确名称重试；不要试图用go mod edit -module修复，容易残留缓存引用
国内拉依赖慢？别只配 GOPROXY
设了 export GOPROXY=https://goproxy.cn 还卡在 go get，大概率是 GOSUMDB 在校验阶段被墙——它默认连接 sum.golang.org，超时后不 fallback，直接中断。
- 同步关闭校验：
go env -w GOSUMDB=off（仅开发机适用） - 或换可信镜像：
go env -w GOSUMDB=sum.golang.google.cn - 注意：二者必须同开同关，单独配
GOPROXY而不调GOSUMDB，某些私有模块或带 checksum 的 vendor 仍会失败
环境搭得越“干净”，后面加中间件、接 gRPC、跑单元测试时出的岔子就越少；最麻烦的从来不是语法，而是某个隐藏的 go env 值在某次 go mod tidy 时悄悄改变了行为。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
