配置热重载需绕过进程重启，通过fsnotify监听配置文件变更并原子更新内存变量，配合sync.RWMutex保证线程安全，同时重构中间件为函数工厂模式以实时获取最新配置值。
配置热重载 ≠ 代码热重载
直接用 gin 命令（如 gin run main.go）只能监听 Go 源码变化、触发编译重启，对 conf/app.ini 这类业务配置文件完全无感。改完配置保存，服务不会自动重读——这是新手最容易混淆的点。
真正要热重载的是运行时读取的配置值（比如 JWT 密钥、分页大小、Redis 地址），不是代码逻辑本身。所以必须绕过“进程重启”路径，走内存变量更新路线。
- 配置文件变更后，需主动调用
setting.Setup()或类似初始化函数重新解析 INI - 结构体字段必须是可写且线程安全的（推荐用
sync.RWMutex包裹整个配置对象） - 避免在 handler 里直接引用全局配置指针——万一正在写入，读取可能看到部分更新的脏状态
用 fsnotify 监听配置文件变化
fsnotify 是最轻量、最可控的选择。它不依赖外部进程或信号，纯 Go 实现，适合嵌入到 Gin 启动流程中。
关键不是“监听到就 reload”，而是“监听到 + 校验通过 + 原子替换”。否则配置写错半行，直接把线上服务搞挂。
- 监听
conf/app.ini的WRITE和CHMOD事件（编辑器保存常触发后者） - 收到事件后，先用
cfg, err := ini.Load("conf/app.ini")尝试加载，err != nil则丢弃本次变更 - 校验通过后，用
mutex.Lock()→mapTo("app", &AppSetting)→mutex.Unlock()更新内存配置 - 别忘了在
main()里启动监听 goroutine，并用defer watcher.Close()确保资源释放
HTTP 接口触发手动重载（适合灰度/运维场景）
有些环境禁止文件系统监听（比如只读容器），或者你只想在确认配置无误后才生效——这时提供一个管理接口更稳妥。
注意这个接口必须加权限控制，不能暴露给公网。哪怕只是本地回环，也要用 if c.ClientIP() != "127.0.0.1" 挡一下。
- 注册路由：
router.POST("/debug/reload-config", reloadConfigHandler) - handler 内部执行和 fsnotify 相同的三步：加载 → 校验 → 替换
- 成功后返回
http.StatusOK和当前配置版本号（比如cfg.Section("app").Key("version").Value()） - 失败时返回
http.StatusBadRequest和具体错误（如"invalid port: -1"），别返回堆栈
配置更新后中间件行为没变？检查注入时机
Gin 中间件（比如 JWT 验证、限流）通常在 router.Use() 阶段就绑定了闭包变量。即使你更新了 AppSetting.JwtSecret，旧中间件仍拿着初始化时捕获的老值。
这不是 bug，是 Go 闭包的正常行为。解决方法只有两个：
- 把配置读取逻辑从闭包移进 handler 内部，每次请求都走
configMutex.RLock()读最新值（适合低频配置，如开关） - 用函数工厂模式重构中间件：
func NewAuthMiddleware(getSecret func() string) gin.HandlerFunc，启动时传入func() string { return appConfig.JwtSecret }，这样每次调用都取当前值
最易被忽略的是：配置热重载后，旧连接里的 context.Value 可能还缓存着老配置衍生的数据（比如解析出的 token claims）。这类状态需要业务层自己清理或标记失效。
