可靠系统的Golang环境必须从第一天起锁定版本、隔离依赖、约束构建行为；go mod init需带明确模块路径，GO111MODULE=on和GOPROXY必须显式配置，go.sum校验须纳入CI强制检查，Docker中无需设置GOROOT/GOPATH。
可靠系统的Golang环境不是装完Go就能跑，而是从第一天起就锁定版本、隔离依赖、约束构建行为——否则线上行为和本地不一致是大概率事件。
go mod init必须带明确模块路径
很多团队用go mod init时不写参数，结果生成module 空行或module example.com这类占位符，后续导入路径混乱、CI构建失败、跨项目引用出错。
- 模块路径应与代码仓库地址一致，比如GitHub仓库
github.com/your-org/your-service，就该执行go mod init github.com/your-org/your-service - 避免使用
.或./作为模块名，GoLand和CI工具可能解析异常 - 初始化后立刻检查
go.mod第一行是否为预期路径，不是就删掉重来，别靠go mod edit -module补救——它不修正已有import语句
GO111MODULE=on + GOPROXY=https://goproxy.cn
不显式启用Modules或没配代理，go get会 fallback 到 GOPATH 模式，导致依赖下载失败、版本漂移、甚至静默覆盖本地修改。
- 在shell配置文件（
~/.zshrc或~/.bashrc）中固定设置：export GO111MODULE=on和export GOPROXY=https://goproxy.cn,direct - 验证方式：运行
go env GO111MODULE输出on，go env GOPROXY含goproxy.cn - 企业内网若禁外网，可自建
athens或goproxy.io私有代理，但必须确保所有开发者统一指向同一代理地址，不能混用
Docker多阶段构建中GOROOT和GOPATH不需显式设置
常见误区是在Dockerfile里写ENV GOROOT=/usr/local/go或ENV GOPATH=/go，其实Go 1.16+已默认识别标准路径，硬写反而干扰构建缓存、增加镜像体积。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 基础镜像用
golang:1.21-alpine或golang:1.21-slim即可，无需额外设环境变量 -
go build命令在build stage中直接调用，Go会自动定位SDK和模块缓存 - 最终生产镜像只COPY二进制文件，完全不包含Go SDK，所以GOROOT/GOPATH在runtime镜像里根本不存在——也不需要
go.sum校验必须纳入CI强制检查
go.sum被忽略或手动删改是线上行为不一致的高频原因。它不是“可选清单”，而是模块完整性和确定性的唯一凭证。
- CI流程中加入
git diff --exit-code go.sum，任何未提交的go.sum变更都阻断合并 - 禁止在CI中执行
go mod tidy后再提交——这会让CI和开发者本地状态脱节；tidy只应在本地开发完成时手动触发 - 若发现
go.sum频繁变动，大概率是某依赖用了replace指向本地路径，或用了latest这种不稳定的版本标识，必须清理
真正卡住可靠系统的，往往不是并发模型或架构设计，而是go.mod里一行错误的require、go.sum里一个被跳过的校验、或者Docker构建时多写的那行ENV GOPATH——这些细节不盯死，再好的代码也跑不稳。
