不能直接用init()读配置文件，因其在包导入时执行，此时命令行参数和环境变量尚未解析，无法确定配置文件路径，易导致panic或字段为零值；应将加载逻辑移至main()开头，在flag解析后显式调用。
为什么不能直接用 init() 读配置文件
因为 init() 在包导入时就执行，此时命令行参数、环境变量都还没解析，你根本不知道该加载哪个配置文件。比如想根据 -env=prod 加载 config.prod.yaml，但 init() 里连 flag 都没 parse 过，flag.Lookup("env") 返回 nil。
常见错误现象：panic: runtime error: invalid memory address 或配置字段全为零值，调试时发现 os.Args 还是默认值，压根没生效。
- 把配置加载逻辑放到
main()开头，确保 flag 解析完成后再调用 - 或封装成函数，在
main()中显式调用，比如loadConfig(flagEnv) - 避免在
var声明时直接调用yaml.Unmarshal—— 它依赖外部文件，不是纯初始化
viper 动态切换配置文件路径的正确姿势
viper 默认支持自动重载，但“动态加载”不等于“自动热更新”。它只监听文件变化（需开启 viper.WatchConfig()），而你真正需要的是：启动时根据参数决定读哪个文件，并且后续不再切换源文件。
关键点在于：不要反复调用 viper.SetConfigFile() + viper.ReadInConfig()，这会覆盖已注册的键值映射，导致 viper.Get("db.host") 失效。
- 只在首次加载前设置一次
viper.SetConfigFile()，之后用viper.MergeConfigMap()合并运行时参数 - 若要支持多环境，推荐用
viper.AddConfigPath("./configs")+viper.SetConfigName("config")+viper.SetConfigType("yaml")，再通过viper.SetEnvPrefix("APP")补充环境变量覆盖 - 务必检查
viper.ReadInConfig()的 error，否则静默失败——常见错误信息：Config File "config" Not Found in "[./configs]"
手写配置加载函数时如何避免结构体零值陷阱
Go 的结构体字段默认为零值，如果配置文件缺失某个字段，yaml.Unmarshal 不会报错，而是保留字段初始值（如 int 是 0，string 是 ""）。这在数据库端口、超时时间等关键字段上极易引发线上故障。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
解决思路不是靠文档约定，而是代码层防御：
- 所有必需字段加
yaml:",required"标签（注意：标准gopkg.in/yaml.v3不支持，得用github.com/go-yaml/yaml/v3并手动校验） - 加载后立即调用校验函数，例如：
if cfg.DB.Port == 0 { return errors.New("DB.Port is required") } - 对敏感字段（如密码、密钥）使用指针类型，利用
nil区分“未设置”和“空字符串”，避免误判
热重载配置时 goroutine 和锁的典型误用
有人会在 viper.WatchConfig() 回调里直接修改全局配置结构体，结果并发请求读到一半新一半旧的数据——这不是线程安全操作。
真正安全的做法是：用原子替换（atomic pointer swap）或读写锁保护整个配置实例，而不是只锁某个字段。
- 定义
var config atomic.Value，加载完新配置后调用config.Store(&newCfg) - 读取时统一用
cfg := config.Load().(*Config)，保证看到的是完整快照 - 切忌在回调里直接赋值
globalConfig = newCfg—— Go 没有内存屏障保障，其他 goroutine 可能读到中间状态 - 如果用了
sync.RWMutex，注意Lock()必须在写入前获取，且不能只锁部分字段；读操作用RUnlock()，别漏掉
最易被忽略的是：热重载后，旧连接池、日志句柄等依赖配置的对象不会自动刷新，这部分必须由业务代码显式重建或触发 reload 方法。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
