Fiber 不支持运行时增删路由，必须全量重建 fiber.App 实例并原子替换指针才能安全热更新；重复注册相同 method+path 会 panic，因路由树在 Listen 后变为只读，且 app 实例非线程安全。
Fiber 本身不支持运行时增删路由，必须重建 fiber.App 实例才能安全热更新路由表。 它的 app.Get/app.Post 等方法底层调用的是不可变路由树构建逻辑，重复注册相同 method+path 会 panic；直接在 handler 里调用注册函数还会引发竞态。这不是配置问题，而是设计限制。
为什么 fiber.AddRoute 或 app.Get 在运行时调用会 panic
Fiber 的路由注册（如 app.Get("/api/user", h)）本质是往内部 tree 结构追加节点，但该结构在第一次 app.Listen() 后就进入只读状态。后续再调用会触发：panic: method GET is already registered for path "/api/user"。
- 哪怕你用
app.Use注册中间件拦截后再动态匹配，也无法绕过这个 panic —— 因为app实例本身不是线程安全的路由容器 - 试图用
sync.RWMutex包裹app.Get调用也没用：锁住的是调用动作，不是路由树的可变性 - 别信“用
app.New()新建子实例然后挂载”的方案——Fiber 没有New()方法，fiber.New()返回的是全新独立实例，无法嵌套或合并
正确做法：全量重建 app 实例 + 原子替换指针
和 gorilla/mux 或 gin.Engine 类似，Fiber 必须走「新实例构建 → 校验 → 原子替换」路径。关键不是怎么注册，而是怎么切换。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 定义一个全局可原子替换的指针：
var appPtr atomic.Value，初始值设为fiber.New() - 每次 reload 时，先调用
newApp := fiber.New()，再按需注册所有路由（包括中间件、静态文件、错误处理等） - 校验新实例是否能正常响应（例如用
httptest.NewUnstartedServer(newApp.Handler())发个健康检查请求） - 通过
appPtr.Store(newApp)替换旧实例；老实例会随已有连接自然退出，GC 自动回收 - HTTP server 的
Handler必须从指针取值：http.ListenAndServe(":3000", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { appPtr.Load().(*fiber.App).Handler().ServeHTTP(w, r) }))
配合 viper 实现配置驱动的路由热加载
路由规则得从某处来，推荐用 viper 加载 YAML 配置并监听变更，但注意它不会自动触发 Fiber 重建 —— 你需要自己写回调。
立即学习“go语言免费学习笔记（深入）”；
-
viper.WatchConfig()只发事件，不解析也不重载；必须在viper.OnConfigChange回调里显式调用viper.Unmarshal(&routeConfig) - 结构体字段必须首字母大写且带
yaml:tag，例如：Path string `yaml:"path"`、Method string `yaml:"method"` - 别在回调里直接调
app.Get—— 此时app还在服务请求，修改会导致 panic 或 404 - 回调中应启动一个 goroutine 执行全量重建流程，避免阻塞 fsnotify 事件循环
- 配置校验必须包含
Method是否合法（GET/POST等）、Path是否以/开头、Target地址能否连通（可用http.Head快速探测）
最易被忽略的一点：Fiber 的 StrictRouting 默认开启，/users 和 /users/ 是两个不同路由。如果你的配置里只写了 path: "/users"，但用户访问的是 /users/，就会 404 —— 这个行为不会因热更新而改变，必须在配置层或中间件层统一处理，不能指望 reload 修复路径匹配逻辑。
