真正整洁的多环境配置核心是配置来源分层、可覆盖、不可泄露；viper需显式设置带环境后缀的文件名，addconfigpath须在setconfigname前调用，搜索路径为逆序，敏感字段禁入yaml而应通过环境变量注入，readinconfig不报错需手动校验。
Go 项目里配置不分离，上线前改 config.yaml、临时 export APP_ENV=prod、本地调试时密钥硬编码进文件——这些操作不是“快”，是埋雷。真正整洁的多环境配置，核心就一条：配置来源必须分层、可覆盖、不可泄露。
用 Viper 加载配置时，为什么 config.dev.yaml 总被忽略？
Viper 默认不会自动拼接环境名到文件名，viper.SetConfigName("config") 就只会找 config.yaml，不会管你当前是 dev 还是 prod。
- 必须显式构造带环境后缀的文件名：
viper.SetConfigName(fmt.Sprintf("config.%s", env)) -
viper.AddConfigPath("./config")要在SetConfigName之前调用，否则路径无效 - 如果同时加载了多个配置路径，Viper 按
AddConfigPath的**逆序**搜索（最后加的路径优先），容易误读错文件 - 别依赖
viper.AutomaticEnv()自动映射所有字段——它只对大写 + 下划线变量生效，且和结构体字段名大小写不一致时会失效
敏感字段（如 DB_PASSWORD）为什么不能写进 YAML 文件？
YAML 文件一旦提交进 Git，就等于把密码公开。哪怕加了 .gitignore，也挡不住新人手误或 CI 环境自动拉取。
- 生产环境必须通过环境变量注入：
DB_PASSWORD=xxx go run main.go，然后在代码中用viper.GetString("db.password")直接读取 - Viper 的优先级链是：命令行参数 > 环境变量 > 配置文件 > 默认值。只要环境变量名匹配（如
DB_PASSWORD对应db.password），就会自动覆盖 YAML 中的值 - 本地开发可用
godotenv.Load(".env.local")加载未提交的 .env 文件，但该文件必须在.gitignore中，且不能包含任何生产密钥
Makefile 切换环境时，APP_ENV=dev 不生效？
Makefile 中的变量赋值默认只在当前 shell 命令行生效，APP_ENV=dev go run main.go 这种写法在某些 shell 或 Make 版本下会被截断或忽略。
- 正确写法是用
export显式导出：run-dev: export APP_ENV=dev; go run main.go
- 更可靠的做法是用
env命令包裹：run-dev: env APP_ENV=dev go run main.go
- CI/CD 中建议统一用
env:块定义变量，避免 Makefile 解析歧义 - 别在 Makefile 里写
APP_ENV ?= dev—— 这只是 Make 变量，默认值，不会传给 Go 进程
最易被忽略的一点：Viper 的 ReadInConfig() 不会报错当配置文件缺失，它只默默跳过；而 Unmarshal(&cfg) 也不会校验必填字段是否为空。这意味着一个空的 config.prod.yaml 可能让你的服务连数据库都连不上，却没有任何提示——必须手动调用 viper.GetBool("required.field.set") 或用结构体标签做启动时验证。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
