Go环境搭建核心共识是：GOROOT与GOPATH必须物理隔离，GO111MODULE需设为on，GOPROXY必须配置可用代理，go mod init须带完整module path，CI中禁止依赖~/.bashrc。
Go 语言环境搭建没有“行业标准”意义上的强制规范，但存在被广泛采纳、经生产环境验证的实践共识。这些共识不是靠文档规定出来的，而是由 Go 官方工具链行为、模块机制演进和主流团队落地经验共同沉淀下来的。
go version 和 go env 输出必须稳定可预期
安装后执行 go version 和 go env 不应报错，且关键变量值需符合最小约束：
-
GOROOT必须指向真实存在的 Go 安装根目录（如/usr/local/go），不能是空或错误路径 -
GOPATH在 Go 1.16+ 可设为任意路径，但若未显式设置，go env GOPATH会 fallback 到$HOME/go；建议显式声明，避免不同用户/CI 环境行为不一致 -
GO111MODULE应明确设为on（推荐）或auto，禁用off—— 否则go mod命令不可用，依赖管理退回到不可控的 GOPATH 模式 -
GOPROXY必须配置可用代理（如https://proxy.golang.org,direct或国内镜像），否则go get或go mod download在无网络或墙环境下必然失败
GOROOT 与 GOPATH 的物理隔离是硬性要求
二者目录不能嵌套，也不能重合。常见错误包括：
- 把
GOPATH设为/usr/local/go（即和GOROOT相同）→ 导致go install覆盖标准库或破坏工具链 - 把
GOPATH设在GOROOT/src下 →go build可能误将项目代码当作标准库一部分编译 - 多个项目共用同一
GOPATH/src但未按github.com/user/repo结构组织 →go mod init生成的 module path 与实际 import 路径不匹配，引发 import cycle 或找不到包
正确做法：GOROOT 固定只放 Go 官方二进制和标准库；GOPATH 单独指定一个干净目录（如 /data/go），其下 src 仅用于存放你自己的代码或 fork 的第三方仓库。
立即学习“go语言免费学习笔记（深入）”；
Go Modules 初始化必须带明确 module path
在项目根目录运行 go mod init 时，必须传入完整且可解析的 module name，例如：
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
go mod init github.com/myorg/myapp
而不是：
go mod init myapp
原因：
- module path 是 Go 依赖解析的唯一标识，影响所有
import语句的匹配逻辑 - CI/CD 中若用相对路径初始化，不同 clone 路径会导致
go list -m all输出不稳定 - 发布到私有 registry（如 Artifactory）时，module path 必须与 registry 的 repository root 对齐，否则
go get无法定位
注意：go mod init 不会自动创建 go.sum，首次 go build 或 go test 才会生成并锁定依赖版本。
CI 环境中禁止依赖 $HOME/.bashrc 或交互式 shell 配置
很多团队在 Jenkins/GitLab CI 中直接复用本地 ~/.bashrc 里的 export，结果失败。根本原因是：
- CI runner 多数使用 non-login、non-interactive shell，
~/.bashrc默认不 source -
GOROOT和PATH必须在 CI 脚本开头显式设置，例如：
export GOROOT=/opt/go export PATH=$GOROOT/bin:$PATH
更稳妥的做法是：在 CI 配置中直接用绝对路径调用 /opt/go/bin/go，绕过 PATH 查找；同时用 go env -w 写入临时环境变量，避免污染全局配置。
真正容易被忽略的点在于：Go 工具链本身不校验 GOPATH 是否可写，但 go mod download 会在 $GOPATH/pkg/mod 缓存依赖——如果该路径权限不足或磁盘满，错误往往表现为模糊的 “no required module provides package” 而非明确的 permission denied。
