Viper 实现配置热加载与环境隔离需动态拼接文件名（如 "config-" + os.Getenv("ENV")）、调用 AutomaticEnv() 和 SetEnvKeyReplacer 处理环境变量映射、用 Unmarshal 做结构体强类型校验，并通过 MergeConfigMap 合并通用配置，禁止硬编码与敏感信息注入。
生产环境不能靠改代码切配置，必须用环境变量或外部配置文件驱动；硬编码、if env == "prod" 这类写法在上线前就会被运维拦下来。
如何用 Viper 实现配置热加载与环境隔离
Viper 是 Go 生态中事实标准的配置库，它天然支持多环境切换，关键不是“怎么读 YAML”，而是怎么让不同环境读到不同的值而不冲突。
- 配置文件按环境拆分：
config.dev.yaml、config.prod.yaml，再加一个通用的config.common.yaml，通过viper.MergeConfigMap()合并 - 环境变量优先级必须高于文件：调用
viper.AutomaticEnv()后，APP_SERVER_PORT会自动映射到server.port - 别直接用
viper.GetString("server.port")—— 先定义结构体，用viper.Unmarshal(&cfg)做类型安全校验，避免运行时 panic - 开发时用
viper.SetConfigName("config.dev")，生产镜像里只挂载config.prod.yaml并设ENV=prod，Viper 会自动 fallback 到config.common.yaml
Docker 镜像里怎么安全传入生产配置
配置不能打包进镜像，尤其数据库密码、密钥这类敏感字段。K8s 中用 ConfigMap/Secret 挂载是底线，但本地测试和 CI 构建阶段也得一致。
- 启动容器时用
-v /path/to/config.prod.yaml:/app/configs/config.yaml:ro挂载，确保路径和 Viper 的AddConfigPath()一致 - 禁止用
ENV CONFIG_CONTENT="xxx"注入整个配置字符串 —— 容器日志、docker inspect全能看见，且 YAML 编码易出错 - 如果非要用环境变量传个别字段（比如临时覆盖端口），用
viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_"))，这样server.port对应SERVER_PORT - CI 构建阶段不要
COPY config.prod.yaml到镜像里，只保留config.common.yaml，否则镜像一推到仓库就等于泄露配置
Gin 启动时如何验证配置有效性
很多线上故障源于配置缺失或类型错误，比如 redis.port 写成字符串 "6379" 而不是整数，Gin 启动不报错，但第一次连 Redis 就 panic。
- 在
LoadConfig()函数末尾加显式校验：检查cfg.Database.Host != ""、cfg.Server.Port > 0 && cfg.Server.Port - 对必填字段用
viper.IsSet("database.host")主动判断，而不是等下游组件报错 - 日志里打印已加载的配置项（脱敏后）：只打 key 和类型，比如
"database.host: string, redis.port: int"，不打值 - 健康检查接口
/healthz里加入配置连通性验证：尝试 ping Redis、连接 DB，失败则返回 503，让 K8s probe 快速发现
最常被忽略的一点：配置热更新不是“改完 YAML 自动生效”，Viper 默认不监听文件变化。需要手动调用 viper.WatchConfig() 并注册回调，且 Gin 的中间件、DB 连接池这些对象不会自动重载 —— 你得自己 reload 或重启服务。生产环境更推荐“配置即不可变”，靠滚动更新替代热更新。
