flag和os.Args不适合动态重载配置，因为flag.Parse()仅在进程启动时解析一次，os.Args仅反映初始命令行参数，二者均无法响应运行时文件变更；必须借助fsnotify监听文件事件，配合原子替换与并发安全机制实现热加载。
为什么 flag 和 os.Args 不适合动态重载配置
启动时读一次配置是够用的，但服务运行中配置变更（比如限流阈值、开关状态）必须实时生效——flag.Parse() 只在进程初始化阶段生效，os.Args 更是只反映启动参数，两者都无法响应文件内容变化。硬重启服务代价高、有损，所以得绕过启动期绑定，自己监听+解析。
用 fsnotify 监听文件变更再热加载
Go 生态最常用的是 fsnotify 库，它封装了 inotify（Linux）、kqueue（macOS）、ReadDirectoryChangesW（Windows）等系统调用，能可靠捕获文件写入事件。注意：不要监听整个目录，只监听具体配置文件路径，避免误触发；也不要监听 WRITE 事件本身，而应等待 CHMOD 或 ATTRIB 后再读——因为很多编辑器（如 vim）会先写临时文件再原子重命名，直接读可能读到不完整内容。
- 安装：
go get github.com/fsnotify/fsnotify - 注册监听前先
os.Open一次确保文件存在，否则监听会失败 - 收到
fsnotify.WriteEvent后，sleep 100ms 再os.ReadFile，避开编辑器写入中间态 - 解析失败时保留旧配置，打日志但不 panic，避免配置错误导致服务中断
json.Unmarshal 和 yaml.Unmarshal 的结构体字段必须导出
反射解析依赖字段可导出（首字母大写），如果配置结构体里用了小写字段名，json.Unmarshal 或 yaml.Unmarshal 会静默忽略对应键，导致字段始终为零值——这比解析报错更难排查。
type Config struct {
Timeout int `json:"timeout" yaml:"timeout"`
Enable bool `json:"enable" yaml:"enable"`
// ❌ 错误示例：lowercase field
logLevel string `json:"log_level"` // 永远不会被赋值
}
另外，YAML 解析推荐用 gopkg.in/yaml.v3，它支持别名、锚点和更严格的类型推断；JSON 则直接用标准库 encoding/json 即可，无需额外依赖。
立即学习“go语言免费学习笔记（深入）”；
并发安全的配置更新要靠 sync.RWMutex 或 atomic.Value
多个 goroutine 同时读配置是常态，但写只能串行。用 sync.RWMutex 最直观：读操作加 RLock，写操作用 Lock + 替换指针。如果配置结构体很大且更新频繁，atomic.Value 更高效——它允许无锁读，写时用 Store 替换整个结构体指针。
- 别在锁内做耗时操作（如文件 I/O 或网络请求），只做解析和赋值
- 更新后广播信号（比如通过
chan struct{}）通知其他模块刷新内部状态 - 避免在 HTTP handler 里直接调用
config.Load()，应预先缓存引用
真正麻烦的不是监听或解析，而是配置项语义变更时的兼容性处理——比如旧版配置没 retry_count 字段，新版加了默认值，这种逻辑得写在 Unmarshal 后的校验函数里，而不是靠 tag 自动填充。
