go环境搭建虽简化，但需确保go111module=on、goproxy配置正确，并在含go.mod的目录执行命令，否则易报“no required module provides package”等错误。
Go 环境搭建现在远比 2016 年简单，GOROOT 和 GOPATH 不再是必配项，但盲目跳过仍会导致 go build 失败、模块下载卡住、或 go run 报 no required module provides package —— 这些问题本质不是“装没装好”，而是环境状态和项目模式不匹配。
Go 1.16+ 默认启用 module 模式，GOPATH 已非必需
从 Go 1.16 开始，GO111MODULE=on 成为默认行为。这意味着：
- 只要项目根目录下有
go.mod文件，go命令就按模块方式工作，不再依赖GOPATH/src目录结构 -
GOPATH仅用于存放下载的依赖缓存（$GOPATH/pkg/mod）和go install生成的二进制（$GOPATH/bin），不强制要求你把代码放进去 - 如果你用
go mod init myapp初始化项目，后续所有go build、go run都自动识别当前模块，无需设置GOPATH
验证方式：go env GOPATH 会输出一个默认路径（如 $HOME/go），但你完全可以在任意目录新建项目并正常构建。
go env -w 设置代理和模块开关比改 shell 配置更可靠
国内用户常遇到 go get 卡在 proxy.golang.org 或超时，直接写入环境变量比修改 .bashrc 更快生效且避免 shell 加载顺序问题：
- 运行
go env -w GO111MODULE=on确保模块始终开启（即使你在旧项目里执行go build） - 运行
go env -w GOPROXY=https://goproxy.cn,direct切换到国内镜像；direct表示对私有域名（如公司内网模块）直连，不走代理 - 如果需要跳过证书校验（仅限测试环境），加
go env -w GOSUMDB=off，但生产环境严禁关闭校验
这些设置会写入 $GOPATH/go.env，优先级高于 shell 中的 export，且跨终端生效。
go run 和 go build 对目录结构敏感，别混用老式 GOPATH 习惯
常见错误：在非模块根目录下执行 go run main.go 却报错 cannot find module providing package。原因是你没在模块根目录运行命令：
-
go run要求当前目录存在go.mod，或能向上找到它；否则它会尝试按 GOPATH 模式查找，但现代 Go 已不推荐这种用法 -
go build同理：若不在模块根目录，且文件未显式指定路径（如go build ./cmd/myapp），可能编译失败或生成位置异常 - 正确做法：进到含
go.mod的目录再运行命令；或用完整路径，如go run ./main.go（注意前面的./）
顺带一提：go build -o ./bin/app 比默认生成在当前目录更可控，避免污染源码树。
Windows 下安装后仍提示 'go' is not recognized 的真实原因
不是 PATH 没加，而是 Windows 安装程序默认只对「当前用户」写入 PATH，而你新开的终端（尤其是以管理员身份运行的 PowerShell 或 VS Code 终端）可能读取的是系统级 PATH：
- 检查方式：在终端里运行
where go，若无输出，说明 PATH 未生效 - 解决方案：重新运行安装包，勾选「Add Go to PATH for all users」；或手动把
C:\Program Files\Go\bin加入「系统环境变量」而非「用户环境变量」 - VS Code 用户额外注意：关掉所有终端窗口，重启 VS Code，否则旧终端进程不会重新加载 PATH
真正麻烦的不是装不上，而是装上了却用错模式——比如在模块项目里还刻意把代码放到 %GOPATH%\src\ 下，结果 go mod tidy 无法解析本地相对路径导入。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
