echo 不自动管理配置，需在 echo.new() 前用 viper 手动加载并解析配置，确保 setconfigname、addconfigpath、setconfigtype、automaticenv 等调用顺序正确，且基础字段置于 config.yaml 以避免空值 panic。
Go 项目用 Echo 框架时，多环境配置切换不靠框架自动识别，而是由你控制配置加载逻辑——Echo 本身不封装配置管理，得靠 viper 或手写加载器来实现，否则 go run main.go 在 dev 环境跑着，一上生产就因读错 config-prod.yaml 而连不上数据库。
为什么 echo.New() 启动后 config.dev.yaml 还是没生效
Echo 不参与配置加载，它只接收一个已解析好的 Config 结构体或直接读环境变量。如果你写了 viper.ReadInConfig() 却没生效，大概率是名字没拼对或时机错了：
-
viper.SetConfigName("config")是错的——它只会找config.yaml，不会根据ENV=prod自动补后缀 - 必须写成
viper.SetConfigName("config-" + os.Getenv("ENV"))，且确保启动前已设ENV=prod -
viper.AddConfigPath("./configs")的路径必须真实存在，Docker 中挂载 ConfigMap 后，即使ls ./configs能看到文件，viper.ReadInConfig()也可能静默失败（查权限是否为644、挂载是否只读） - 必须在
viper.ReadInConfig()前调用viper.SetConfigType("yaml")，否则报Unsupported Config Type ""
viper.AutomaticEnv() 映射 server.port 到 SERVER_PORT 总失败
viper.AutomaticEnv() 默认只做全字符串匹配：结构体字段 ServerPort int `yaml:"server_port"` 对应的环境变量名是 SERVER_PORT，但如果你的 YAML key 是 server.port，viper 就会去找 SERVER.PORT——而系统里根本没有这个变量。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 尽早调用
viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_"))，把点号转下划线 - 加前缀防冲突：
viper.SetEnvPrefix("app")，这样app.server.port对应APP_SERVER_PORT - 特殊映射（比如
PGHOST → db.host）用viper.BindEnv("db.host", "PGHOST")显式绑定 - 别绕过 viper 直接
os.Getenv("SERVER_PORT")——这跳过了优先级链（flag > env > file > default），也丢掉了 fallback 能力
dev/staging/prod 配置怎么避免字段遗漏导致 panic
viper 不自动继承父配置，config.staging.yaml 里只写了 log_level: warn，但没写 db.host，那运行时 db.host 就是空字符串，不是从 config.yaml 里“继承”过来的。
- 基础字段（如
db.host、redis.addr）必须放在config.yaml（默认配置），环境特有字段（如log_level、pool_size）才拆到config-prod.yaml - 如果非要分层覆盖，得手动
viper.MergeConfigMap(map[string]interface{}{...})补全缺失字段，不能依赖“自动合并” - 嵌套结构体 unmarshal 后字段为空？检查
yaml:"xxx"tag 是否大小写敏感、是否和 YAML 文件中 key 完全一致（dbHost和db_host是两回事） - YAML 中的
inherit标签只对 EtcdConf 这类嵌套结构有效，不能跨文件继承
最易被忽略的一点：所有配置加载逻辑必须在 echo.New() 之前完成，且 viper.Unmarshal(&cfg) 后的 cfg 必须传给 Echo 的中间件或服务初始化函数；否则即便文件读进来了，Echo 也压根不知道你配了啥。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
