Go 1.11 后环境搭建核心是装对版本（建议≥1.13）并跳过 GOPATH 陷阱；go mod init 需用可解析模块路径（如 github.com/user/repo），GO111MODULE=on 非万能，国内需配 GOPROXY，模块名写入 go.mod 后不可随意更改。
Go 1.11 之后的环境搭建，核心就两件事：装对版本、跳过 GOPATH 陷阱。现代 Go 项目几乎不再依赖 GOPATH，硬配反而容易引发 go mod 行为异常或 import 路径错乱。
验证 go version 是否满足模块化要求
模块（Module）从 Go 1.11 引入，但真正稳定可用要到 Go 1.13+。低于这个版本，go mod tidy 可能漏依赖，replace 指令行为也不一致。
- 运行
go version，确认输出中包含go1.13或更高（如go1.21.6） - 若版本过低（比如
go1.10.8），直接重装——别试图用GO111MODULE=on强行启用 - Windows 用户注意：MSI 安装包默认不修改系统 PATH，安装后需手动检查
go是否可执行
go mod init 的路径与模块名不是一回事
执行 go mod init 时传入的参数是模块路径（module path），不是文件夹名，也不是将来 import 的前缀。
- 错误示范：
go mod init myapp→ 后续所有import "myapp/xxx"都会失败，除非你真把代码部署到myapp这个域名下 - 正确做法：用实际可解析的路径，比如
go mod init github.com/yourname/myapp或go mod init example.com/myapp - 本地开发没域名？用伪域名也行：
go mod init local/myapp，只要保持内部import路径一致即可 -
go.mod生成后，模块名不可随意改；否则已有import语句全报错，go build直接失败
GO111MODULE=on 不是万能开关
这个环境变量只控制是否启用模块模式，但它不解决路径冲突、代理失效或缓存污染问题。
立即学习“go语言免费学习笔记（深入）”；
- 在 GOPATH/src 下初始化模块？
go mod init会成功，但后续go run可能仍走 GOPATH 查找依赖，导致版本混乱 - 国内用户必须配代理，否则
go mod download卡住或报no matching versions：go env -w GOPROXY=https://goproxy.cn,direct - 遇到奇怪的
cannot find module providing package，先清缓存：go clean -modcache，再go mod tidy - 不要在
~/.bashrc里硬写export GO111MODULE=on—— Go 1.16+ 默认开启，强制设置反而干扰 CI 环境判断
最易被忽略的一点：模块路径一旦写进 go.mod，它就参与了整个构建链路——从 go list -m all 到 go build -v 显示的导入路径，再到 go doc 查文档，全都认这个值。改它，等于重签整个项目的“身份证”。
