必须手动控制配置加载逻辑，即在main()开头调用loadConfig(os.Getenv("APP_ENV"))，用viper.SetConfigName(fmt.Sprintf("config.%s", env))、AddConfigPath("configs")和ReadInConfig()加载对应config.dev.yaml或config.prod.yaml，不可依赖Echo自动识别。
Go 语言中用 Echo 框架做多环境配置切换，不能靠框架自动识别环境，必须手动控制加载逻辑。Echo 本身不提供 config-{env}.yaml 自动加载机制，所有环境差异化都得靠你写代码桥接——比如用 viper 或手写 os.Getenv("APP_ENV") 分支加载。
怎么让 Echo 启动时读对 config.dev.yaml 或 config.prod.yaml
核心是「先加载配置，再传给 Echo 实例」，Echo 不参与配置解析过程。常见错误是把配置加载逻辑塞在 e.GET 之后，或误以为 echo.New() 会自动读环境变量。
- 必须在
main()开头就调用配置加载函数，比如loadConfig(os.Getenv("APP_ENV")) - 推荐用
viper：先viper.SetConfigName(fmt.Sprintf("config.%s", env))，再viper.AddConfigPath("configs")，最后viper.ReadInConfig() - 别漏掉 fallback：如果
APP_ENV为空，应默认走config.dev.yaml或直接 panic 提示缺失环境变量 - 路径权限要检查——
viper.ReadInConfig()失败时不会报具体路径错误，只返回"Config File Not Found"，建议加os.Stat("configs/config.dev.yaml")预检
viper 在 Echo 项目里容易覆盖错的三个点
viper 的行为和直觉有偏差，尤其在多文件叠加时。Echo 项目里最常踩的是「以为写了 prod 文件就能补全字段」，结果运行时报空指针。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 它不自动继承基础配置：如果
config.yaml定义了db.host，而config.prod.yaml只写了db.port: 5432，那db.host在 prod 下就是空——必须显式调用viper.MergeConfigMap(baseConfig)补全 -
viper.AutomaticEnv()默认开启时，DB_URL=xxx会静默覆盖 YAML 里的值，排查时根本看不出哪来的值，开发期建议关掉 -
viper.WatchConfig()只监听最后一次ReadInConfig()加载的文件，不是整个configs/目录；想热更 prod 配置，得单独viper.SetConfigFile("configs/config.prod.yaml")再 Watch
go run 时怎么确保 APP_ENV 生效且不拼错
本地调试时最常卡在这步：写了 if os.Getenv("APP_ENV") == "prod"，但 shell 里执行的是 go run main.go，没设变量，结果永远走 dev 分支。
立即学习“go语言免费学习笔记（深入）”；
- 必须带前缀执行：
APP_ENV=prod go run main.go（Linux/macOS）或$env:APP_ENV="prod"; go run main.go（PowerShell） - 别用
GO_ENV或ENV：和 Go 工具链变量（如GOROOT）冲突，viper默认也不读这些 - 启动脚本里加校验：如果
os.Getenv("APP_ENV") == ""，直接log.Fatal("APP_ENV not set")，避免沉默失败 - 容器部署时，Dockerfile 里写
ENV APP_ENV=prod，比 runtime-e APP_ENV=prod更可靠
真正难的不是写几份 YAML，而是让不同环境下的 db.timeout、log.level、feature.flag 这些字段在代码里始终有确定来源——要么全从 viper 取，要么全走环境变量，混用时优先级极易失控。上线前务必用 viper.AllSettings() 打印完整配置快照，对照预期逐项核对。
