go.mod只负责锁定依赖版本，不参与运行时配置；环境配置需通过viper动态设名、显式绑定环境变量等机制实现，与go.mod完全无关。
go.mod 不负责环境配置，只管依赖版本
很多人误以为 go.mod 能控制配置加载路径或环境行为——它完全不参与运行时配置逻辑。它的唯一职责是锁定依赖模块的版本，比如 github.com/spf13/viper v1.16.0，和你用 config-dev.yaml 还是 config-prod.yaml 毫无关系。
混淆这点会导致：改了 go.mod 里的 viper 版本，却以为能修复环境变量读取失败；或者在 CI 中反复重试 go mod download，而实际问题是 viper.AutomaticEnv() 没调用。
-
go.mod是构建期静态依赖契约，不是运行时配置开关 - 不同环境共用同一份
go.mod是正常且推荐的——配置差异不该靠换依赖来实现 - 若为“开发环境用 viper，生产环境不用”，说明架构已偏离 Go 的简洁原则，应直接删掉 viper，裸用
os.Getenv+ 结构体
viper 加载多环境配置文件必须动态设名，不能靠多次 ReadInConfig
常见错误是写一堆 viper.ReadInConfig() 尝试加载 config.dev.yaml、config.prod.yaml，结果字段被意外 merge：dev 的 log.level: debug 跑进 prod 配置里。
正确做法是让 viper 只读一个文件，名字由 GO_ENV 决定：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 约定文件名格式为
config-<code>GO_ENV.yaml，如config-production.yaml - 初始化时调用
viper.SetConfigName("config-" + os.Getenv("GO_ENV"))，再viper.AddConfigPath("./configs") - 绝不在代码里写
viper.ReadInConfig()多次——viper 不提供“选择性加载”，只有一次生效 - 若需公共基础配置，单独建
config-base.yaml，用viper.MergeConfigFile("./configs/config-base.yaml")显式合并，且必须在SetConfigName之前调用
环境变量绑定必须显式声明，AutomaticEnv() 是高危操作
viper.AutomaticEnv() 默认把所有系统环境变量（包括 HOME、PWD、SHELL）都映射成配置项，极易覆盖结构体字段。比如 HOME=/home/user 会把 cfg.Home 字段悄悄赋值，而你根本没定义这个字段。
安全做法是按需绑定：
- 禁用
viper.AutomaticEnv()，彻底关掉自动映射 - 对每个关键字段显式调用
viper.BindEnv("db.host", "DB_HOST") - 环境变量名必须全大写+下划线，如
DB_PORT→ 绑定到db.port，viper.GetInt("db.port")才能读到 - 敏感字段（如
API_KEY）不设默认值，viper.GetString("api.key")返回空就log.Fatal("missing API_KEY")
测试时环境不可信，GO_ENV 必须在 TestMain 中显式设置
本地执行 GO_ENV=test go test ./... 看似有效，但 CI 流水线或 Docker 容器中，子进程不会继承父 shell 的环境变量，os.Getenv("GO_ENV") 直接返回空字符串，导致测试走错分支甚至 panic。
可靠方案只有这一种：
- 在
TestMain函数里第一行调用os.Setenv("GO_ENV", "test") - 用
defer os.Unsetenv("GO_ENV")清理，避免污染后续测试 - 所有配置初始化逻辑必须收进
NewConfig()函数，禁止在init()里加载——否则测试无法重置状态 - 如果用了
godotenv，测试时直接传入 map 构造环境：env.ParseWithFuncs(cfg, func() map[string]string { return map[string]string{"GO_ENV": "test"} })
最容易被忽略的是：配置加载逻辑必须和 GO_ENV 值强耦合，而不是靠文件存在与否判断环境。比如 GO_ENV=staging 时，代码必须去读 config-staging.yaml，而不是 fallback 到 config-production.yaml。
