go项目环境配置应通过编译期build tags或启动期显式viper绑定实现，禁用automaticenv，强制加载后立即校验约束，避免运行时错误。
Go 项目里所谓“基于环境配置的自动分发与管理”，本质不是靠运行时猜环境，而是靠编译期或启动期**显式控制配置来源**。硬编码 if os.Getenv("ENV") == "prod" 或依赖 viper.AutomaticEnv() 自动映射，只会让配置逻辑散落、校验滞后、测试失效。
用 build tags 在编译期锁定环境分支
这是 Go 官方推荐、最轻量也最安全的方式：每个环境对应一个独立的 .go 文件，如 config_dev.go、config_prod.go，顶部带构建约束注释。
-
//go:build dev（Go 1.17+）或// +build dev（旧版），不能漏掉空行 - 所有文件定义相同的
Config类型和NewConfig()函数，但内部逻辑隔离 - dev 版本可允许
TLSKeyPath为空，prod 版本强制非空——编译失败比运行时报错早得多 - 编译命令必须显式指定 tag：
go build -tags=prod -o server ./cmd/server - ID E 可能误加载多个环境文件，建议文件名含环境标识，且避免在同一个包下混放
用 viper 按优先级合并多源配置（不依赖 AutomaticEnv）
如果必须支持运行时切换（比如容器化部署中通过环境变量控制），viper 是当前最通用的选择，但要用对方式——关键是**禁用自动映射，改用显式规则**。
- 调用
viper.SetEnvPrefix("APP")后，APP_SERVER_PORT才会映射到server.port - 必须配
viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_"))，否则嵌套字段如db.host无法匹配APP_DB_HOST - 禁用
viper.AutomaticEnv()，改用viper.BindEnv("server.port", "APP_SERVER_PORT")显式绑定 - 配置文件按
base.yaml（公共）+dev.yaml（覆盖）组织，用viper.MergeConfigMap手动合并，别依赖ReadInConfig自动选 - 务必在
viper.ReadInConfig()前调用viper.SetConfigType("yaml")，否则报Unsupported Config Type ""
热更新配置时字段不刷新？检查 Unmarshal 调用位置和字段导出性
很多人以为 viper.WatchConfig() 会自动刷新结构体，其实它只触发回调；真正生效要靠你手动反序列化，而且有硬性前提。
- 必须在 watch 回调里再次调用
viper.Unmarshal(&cfg)，传的是地址&cfg，不是值cfg - 所有需更新的字段必须首字母大写（导出），否则
Unmarshal直接跳过 - 嵌套结构体同理：哪怕只有一层
Redis struct { Host string }，Host也得大写 + 加mapstructure:"host"tag - 生产环境禁用
viper.WatchConfig()，文件热更新易引发竞态；etcd/ZooKeeper 场景应自己用 clientv3.Watcher 监听再喂给viper.ReadConfig
配置加载不能写在 init() 里
init() 函数在包导入时就执行，导致配置全局单例、无法 mock、单元测试完全失控。
- 把加载逻辑封装成导出函数，如
LoadConfig() (*Config, error) - 业务代码通过参数接收
*Config，而不是从全局变量或单例里取 - 测试时可直接传入伪造配置，例如模拟 Redis 超时降级场景
- 若用了 viper，初始化过程也要放在该函数内，不要在
main.init()或 config 包的init()中做
最常被忽略的一点：无论用 build tags 还是 viper，**所有环境专属的约束逻辑（比如 prod 必须提供 TLS 证书路径、dev 必须允许 localhost DB）都得在加载后立刻校验，而不是等到第一次使用时才 panic**。延迟校验等于把问题留给线上。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
