结论：工业级Golang微服务配置管理必须用viper+环境变量覆盖+显式路径控制+启动校验四件套；config.dev.yaml不生效主因是viper未通过AddConfigPath指定搜索路径，且SetConfigType必须在ReadInConfig前调用，AutomaticEnv会自动覆盖配置项，多环境应通过SetEnvPrefix和SetEnvKeyReplacer实现约定映射，敏感信息禁止写入YAML而只通过环境变量注入，并需在WatchConfig回调中重新Unmarshal结构体。
直接说结论：别用硬编码配置，也别靠改代码切环境；工业级 Golang 微服务的配置管理，必须靠 viper + 环境变量覆盖 + 显式路径控制 + 启动校验 四件套组合拳，缺一不可。
为什么 config.dev.yaml 总是不生效？
根本不是文件名写错了，而是 viper 没找到它。默认只在当前工作目录搜，而你把 config/dev.yaml 放进了子目录却没告诉 viper 去哪找。
- 必须显式调用
viper.AddConfigPath("config")，不能只靠viper.SetConfigName("config.dev") -
viper.SetConfigType("yaml")必须在viper.ReadInConfig()之前调用，否则报错Unsupported Config Type "" - 如果同时用了
viper.AutomaticEnv()，环境变量会自动覆盖配置项——哪怕你加载的是dev.yaml，DB_URL还是会被DB_URL=xxx覆盖，这是设计行为，不是 bug
如何让 APP_ENV=prod 自动加载 config.prod.yaml？
别写一堆 if env == "prod" 切文件名，容易漏 case、难维护。用 viper 的命名约定机制更稳：
- 统一设前缀：
viper.SetEnvPrefix("app")，这样APP_SERVER_PORT就能映射到server.port - 加键替换器：
viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_"))，让viper.GetInt("database.timeout")对应环境变量APP_DATABASE_TIMEOUT - 配置文件仍按环境拆分：
config/base.yaml（公共）+config/prod.yaml（覆盖），但要用viper.MergeConfigMap手动合并，ReadInConfig不支持多文件叠加
怎么防止 dev 环境连上生产数据库？
光靠文件隔离远远不够。真实事故往往发生在：开发改完 config.dev.yaml 提交，CI 自动部署时误用了它，或者环境变量没清理干净。
立即学习“go语言免费学习笔记（深入）”；
- 所有敏感字段（
database.dsn、redis.addr、jwt.secret）禁止出现在 YAML 文件里，只允许通过环境变量注入 - YAML 只存非敏感、可版本化的参数：超时时间、重试次数、feature flag 开关
- 在
main()开头加硬性校验：if os.Getenv("APP_ENV") == "prod" && strings.Contains(os.Getenv("DB_DSN"), "localhost") { log.Fatal("refusing to run prod with local DB") }
热更新配置时结构体字段没变？
viper.WatchConfig() 只触发回调，不会自动刷新你已定义的结构体字段。常见错误是以为监听了就万事大吉。
- 必须在 Watch 回调里重新执行
viper.Unmarshal(&cfg)，且cfg必须传地址（&cfg），不能传值 - 确保结构体所有字段首字母大写（导出），否则
Unmarshal直接跳过 - 如果是 etcd 场景，
viper不原生支持 prefix 监听，得自己用clientv3.Watcher监听变更，再把新内容喂给viper.ReadConfig(bytes.NewReader(data))
最常被忽略的一点：配置文件原子写入。下发新配置时，直接 os.WriteFile("config.yaml", data, 0644) 是危险操作——进程可能读到截断或语法错误的中间态。唯一可靠方式是先写临时文件 config.yaml.tmp，校验 YAML 格式成功后，再用 os.Rename 原子替换。
