核心是用 env 环境变量（如 env=prod）动态拼接配置文件名（如 config.prod.yaml），再通过 viper.setconfigfile() 或 addconfigpath + setconfigname 显式指定，禁用 init() 初始化和硬编码路径，确保测试可覆盖、部署免重编译。
怎么让 viper 按 ENV 加载不同配置文件
核心是别让 viper 自己猜，得明确告诉它“现在要读哪个文件”。Gin 本身不参与配置加载，全靠你手动控制 viper 的 SetConfigFile 或 AddConfigPath + SetConfigName 组合。
常见错误是写死 viper.SetConfigFile("config.dev.yaml")，结果部署时改代码、重新编译，或者用 init() 提前加载，导致测试环境跑不起来（比如 go test 无法覆盖不同 ENV）。
- 正确做法：先读
os.Getenv("ENV")或命令行参数（如-env=prod），再拼出文件名，最后调用viper.ReadInConfig() - 推荐路径约定：
./config/config.dev.yaml、./config/config.prod.yaml，避免把环境名硬编码进结构体 tag - 必须加
viper.AutomaticEnv()，否则环境变量（如DB_HOST）不会自动 fallback 到配置字段 - 加载失败时，
viper.ReadInConfig()会返回 error，别忽略它——直接log.Fatal(err)或 panic，比静默失败好排查
flag 参数和环境变量的优先级怎么设才合理
生产服务启动必须支持多层覆盖：命令行 > 环境变量 > 配置文件。否则上线后改个端口还得改 YAML，运维没法接受。
例如 -port=9000 应该无条件覆盖配置文件里的 server.port，而 ENV=prod 只影响配置文件名，不覆盖字段值。
- 用
flag.Int("port", 0, "...")定义参数，解析后显式赋值给配置结构体字段，不要依赖viper.GetInt("server.port")直接取 - 环境变量命名统一加前缀，比如
MYAPP_DB_HOST，再配viper.SetEnvPrefix("MYAPP")，避免污染全局环境 - 禁用
viper.BindEnv("db.host", "DB_HOST")这种单点绑定——它和AutomaticEnv冲突，且不可预测 - 调试时用
viper.DebugWriter输出最终生效的键值对，确认覆盖顺序是否符合预期
为什么微服务里不能共用一份 config.yaml
不是技术做不到，而是会立刻在服务注册、熔断阈值、日志级别这些地方踩坑。比如用户服务设了 timeout: 5s，订单服务却设了 timeout: 30s，网关转发时超时策略就乱套了。
每个微服务的配置粒度必须独立：数据库连接池大小、重试次数、下游服务地址、指标上报间隔……这些都跟业务逻辑强耦合，强行复用只会让配置越来越臃肿、越来越难维护。
- 配置中心（如 Nacos、Consul）是解法，但本地开发阶段仍需文件隔离——建议按服务名拆配置目录：
./config/user-service/config.prod.yaml - 禁止在代码里写
viper.GetString("common.jwt_secret")这类跨服务引用，所有依赖必须显式传入或通过接口注入 - CI/CD 流水线打包时，用
sed或envsubst替换模板配置，而不是运行时动态拼接
gin.SetMode() 和配置加载顺序有冲突吗
有，而且很隐蔽。gin.SetMode(gin.ReleaseMode) 必须在 gin.Default() 之前调用，否则 Logger 中间件仍会输出彩色 debug 日志，干扰日志采集系统。
但更关键的是：模式设置和配置加载谁先谁后，决定了你能不能拿到正确的 debug 开关值。如果先 gin.Default()，再从配置读 debug: true，那 Recovery 中间件已经按 release 模式初始化了，后面改也无效。
- 固定顺序：读 ENV → 加载配置 → 解析
debug字段 → 调用gin.SetMode()→ 创建gin.Engine - 别信文档里 “set mode anytime” 的说法，
gin.Default()内部会立即检查GIN_MODE环境变量并初始化中间件，时机不可逆 - 线上服务必须显式设
GIN_MODE=release，不能只靠配置文件字段，防止配置加载失败时 fallback 到 debug 模式
