Config结构体绑定+多环境文件分离+显式校验是最可控、可测试、无隐式副作用的Go配置管理路径，避免viper隐式行为导致的运行时错误与调试困难。
Config 结构体绑定 + 多环境文件分离 + 显式校验，是当前最可控、可测试、无隐式副作用的 Go 配置管理路径。别一上来就 viper，它默认行为容易让你在上线前半小时还在查“为什么改了 config.yaml 没生效”。
用结构体定义配置，而不是 string key 访问
硬写 viper.GetString("database.host") 或 os.Getenv("DB_HOST") 会导致 IDE 跳转失效、字段名拼错 runtime 才报、重构时无法批量重命名。
正确做法是把所有配置声明为 Go 结构体，字段带明确类型和 tag：
type Config struct {
HTTP struct {
Port int `mapstructure:"port"`
} `mapstructure:"http"`
Database struct {
Host string `mapstructure:"host"`
Port int `mapstructure:"port"`
Username string `mapstructure:"username"`
Password string `mapstructure:"password"`
} `mapstructure:"database"`
}
好处包括：
Port 写成 string 直接报错Config{...} 实例，无需 mock 全局状态viper.Get("db.port") 返回 interface{} 导致的 panic不要依赖 viper 的隐式加载和优先级规则
viper 默认开启 viper.AutomaticEnv()，但没设前缀时会把所有环境变量（如 LOG_LEVEL）映射成小写键 log_level，而你可能只想绑定 APP_* 开头的变量——结果是第三方库的环境变量意外覆盖你的配置。
立即学习“go语言免费学习笔记（深入）”；
更麻烦的是它的多源优先级：命令行 > 环境变量 > 配置文件 > 默认值。表面合理，实际调试时经常发现：
.env 文件里写了 APP_DEBUG=true，但 viper 读的是系统级 DEBUG=1（因未设前缀）viper.ReadInConfig() 成功，但 viper.Unmarshal() 失败，错误信息只说 “cannot decode”，不告诉你哪一行 YAML 格式错viper 实例，前一个 test 清不干净，后一个 test 读到脏数据替代方案：手动读文件 → yaml.Unmarshal → mapstructure.Decode，全程无全局状态、无隐式行为。
按环境拆分配置文件，但不要靠 if-else 切换
别在代码里写 if env == "prod" { load("prod.yaml") } —— 这会让构建产物耦合部署环境，CI 打包时无法验证 prod 配置语法是否合法。
推荐方式是：启动时由外部决定加载哪个文件，例如：
./myapp -config configs/prod.yaml
CONFIG_PATH=./configs/staging.yaml ./myapp
cp configs/${ENV}.yaml configs/app.yaml
关键点：
Password string `mapstructure:"password" envconfig:"DB_PASSWORD"`
yq e -P configs/dev.yaml，提前发现缩进或布尔值大小写问题格式化配置文件不能靠 gofmt
gofmt 对 config.yaml 或 settings.json 完全无效，强行运行会报 cannot format non-Go files。
真实可用的组合是：
gojq --indent 2 . config.json > tmp.json && mv tmp.json config.json
yq -i e -P config.yaml（注意 yq v4.35.1 和 v4.40.0+ 序列化 true 的结果不同，CI 中必须锁死版本）脚本里要过滤掉 vendor/ 和 node_modules/，否则 find 可能扫到第三方 YAML 模板导致失败；路径含空格时，find -exec yq -i 在旧版 yq 下会崩溃，必须用 while read f 安全处理。
