Gin通过viper动态加载配置需用os.Getenv("ENV")获取环境名拼接文件名（如config.dev.yaml），禁用init()初始化以保障测试隔离；开发用YAML，生产优先用环境变量或JSON，并强制校验必填字段。
直接用 viper 动态加载配置文件，别写死路径、别在 init() 里初始化 —— 否则测试跑不起来，上线改不了环境。
怎么让 Gin 根据 ENV 加载 config.dev.yaml 或 config.prod.yaml
核心是靠 os.Getenv("ENV") 拿环境名，再拼出配置文件名。不是硬编码 "config.dev.yaml"，也不是靠目录结构自动识别。
- 启动时传环境变量：
ENV=prod go run main.go或export ENV=test && go run main.go - 代码里用
viper.SetConfigName("config." + env)，再调viper.AddConfigPath("./config")（假设配置文件放在./config/下） - 必须显式调
viper.ReadInConfig()，它只负责读文件，不校验字段是否缺失 - 别在
init()函数里做这事 —— 单元测试时无法重设ENV，viper 会复用旧状态，导致测试环境加载了 prod 配置
为什么开发用 YAML、生产建议用环境变量或 JSON
YAML 在开发阶段确实方便：支持注释、缩进清晰、嵌套可读性强；但上线后它就成了隐患源头。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- YAML 解析比 JSON 慢约 2–3 倍，线上高并发下有感知
-
yes/no/on/off会被隐式转成布尔值，配置项feature.flag: yes可能被当成true，而你根本没定义这个字段类型 - K8s、Docker、云平台基本靠
APP_DB_HOST=xxx这种方式注入配置，YAML 文件反而要额外挂载、权限管理、版本对齐 - 生产环境优先走
viper.AutomaticEnv()+viper.SetEnvPrefix("APP")，再 fallback 到 JSON 文件（viper.SetConfigType("json")），避免 YAML 的歧义解析
配置加载成功 ≠ 配置可用：怎么提前发现字段缺失
viper.ReadInConfig() == nil 只说明文件存在且语法合法，不代表你的服务能正常启动。
立即学习“go语言免费学习笔记（深入）”；
- 比如
viper.GetString("redis.addr")返回空字符串，但实际是忘了在config.prod.yaml里写这一项 - 启动时应显式检查关键字段：
if viper.GetString("db.host") == "" { log.Fatal("missing required config: db.host") } - 更稳妥的做法是定义结构体 +
viper.Unmarshal()，配合mapstructure.DecodeHook做类型校验，空字段会直接报错 - 所有配置项都该有默认值，但「必填项」不能依赖默认值糊弄 —— 默认值只用于非关键兜底，如
viper.GetInt("http.port")可设默认 8080，但db.password不该有默认值
最易被忽略的点：环境变量和配置文件的优先级没理清就上线。viper 默认是「环境变量 > 配置文件」，但如果用了 viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_")) 却忘了同步更新环境变量命名规则，APP.REDIS.ADDR 就永远映射不到 redis.addr 字段。
