17370845950

GOVERSION文件才是Go版本执行依据，必须与go.mod一致并置于根目录；私有proxy需禁用fallback、配置GOINSECURE；全局环境变量须通过shell脚本或Dockerfile设置，禁用go env -w；CI须用目标GOROOT编译校验stdlib兼容性。

Go 版本必须锁死在 go.mod 里，但 GOVERSION 文件才是执行依据

很多人以为只要 go.mod 里写了

go 1.21 就够了，其实 Go 工具链（go build、go test）默认不读它——真正触发版本检查的是项目根目录下的 GOVERSION 文件（Go 1.21+ 支持）。没这个文件，本地用 1.22 跑，CI 用 1.20 跑，embed.FS 行为或 net/http 的 timeout 默认值就可能不一致。

• GOVERSION 文件只写一行，如：go1.21.10（注意无空格、无 v 前缀）
• CI 脚本里必须显式调用 go version 校验，不能只信 gvm 或 asdf 的切换结果
• 团队需统一禁用 GOROOT 手动设置——它会绕过 GOVERSION 检查，导致本地“能跑但 CI 报错”

Go module proxy 必须走私有镜像，且禁止 fallback 到 public proxy

默认 proxy.golang.org 在国内不稳定，更关键的是：一旦它临时不可用，Go 会自动 fallback 到 direct 模式（直连 GitHub），这会暴露公司内网 IP、触发 GitHub 限流，甚至下载到被篡改的依赖。

• 所有机器（含开发机、CI Agent、Docker 构建节点）必须配置 export GOPROXY=https://goproxy.your-company.com,direct（注意末尾 ,direct 是 fallback，要删掉）
• 正确写法是：GOPROXY=https://goproxy.your-company.com，不带 ,direct
• 私有 proxy 需开启 GOINSECURE 对应的内部模块域名（如 git.internal.company.com），否则 go get 会因证书报错

go env -w 是陷阱，团队级配置必须靠 shell 初始化脚本或 Dockerfile

go env -w GOPRIVATE=*.company.com 看似方便，但它写入的是当前用户的 ~/.go/env，对 root 用户、CI Agent 用户、容器内用户完全无效。一次 go env -w 可能只生效于你本机的某个终端 tab。

• 开发机统一用 /etc/profile.d/go-env.sh 设置全局 GOPROXY、GOPRIVATE、GOSUMDB
• Docker 构建必须在 Dockerfile 里用 ENV 显式声明，不能依赖 base image 的预设
• GOSUMDB=off 仅限离线环境；在线环境应设为 sum.golang.org 并配合私有 proxy 缓存校验和，否则 go mod download 会反复失败

Makefile + go list -f 自动检测不兼容的 stdlib 使用

团队升级 Go 版本时，最头疼的是有人偷偷用了新版本才引入的 io.ReadAll 或 slices.Contains，编译不报错（因为本地是新版本），但老版本环境直接 panic。

• 在 Makefile 加一条检查目标：make check-stdlib，核心命令是：go list -f '{{.ImportPath}}' ./... | xargs -I{} go list -f '{{if .Standard}}{{.ImportPath}}{{end}}' {} 2>/dev/null | grep -E '^(io|slices|maps)$'
• 更稳妥的做法是：CI 中用目标 Go 版本的 GOROOT（如 /usr/local/go-1.20）执行 go build -gcflags="-l" ./...，链接阶段会暴露未定义符号
• 禁止在 go.mod 里用 replace 替换标准库——Go 不允许，且 go list 无法识别这种 hack

实际最难落地的不是技术方案，而是让每个 PR 都过 GOVERSION 校验和 GOPROXY 连通性测试——这两项必须嵌进 pre-commit hook 和 CI 入口脚本，缺一不可。