Iris框架的热重载本质是运行时动态重载路由组而非重启进程，需通过Party分组+Reset()清空并重注册，配合iris-admin的permRoutes才能实现带权限、审计、中间件元数据的可运维热重载。
热重载不是 reload main.go，而是重置路由组
Iris 本身不提供文件监听 + 进程重启式的“热重载”（如 Air 或 Fresh），它只支持运行时路由结构的动态重载。真正在开发中提速调试的，是用 Party 分组 + Reset() 清空再注册，而不是反复 go run main.go。否则每次改路由都要等编译、启服务、清浏览器缓存，效率极低。
-
app.Party("/api")返回的是一个可管理的子路由容器，不是字符串前缀 - 必须保存该
group变量引用，后续才能调用group.Reset() -
group.Reset()不影响父级路由（比如/health或/metrics），也不会导致内存泄漏 - 不能对根
app调用Reset()—— 它没有这个方法
宏语法 {id:int min(1)} 必须写死，不能拼接
很多人想从配置里读 "/users/{id}"，再用 strings.Replace 补上 :int min(1)，然后传给 group.Get() —— 这会静默失败。Iris 的 macro 解析发生在路由注册的编译阶段，不是字符串模板渲染。
- 数据库或 YAML 配置中必须存完整路径，例如
"/users/{id:int max(9999)}" - 运行时拼接的字符串会被当作纯路径字面量，
ctx.Params().GetIntDefault("id", 0)永远返回0 - 若需灵活约束（如不同接口要求不同
max值），应提前注册自定义 macro：app.Macros().Int.RegisterFunc("range", rangeValidator) - macro 注册必须在任何
Get/Post调用之前完成，否则新路由无法识别
配合 iris-admin 才算真正可运维的热重载
仅靠 Party.Reset() 只是清掉了路由，但权限、审计、中间件链这些企业级能力全丢了。绕过 iris-admin 直接操作底层 Party，会导致前端菜单还显示按钮、RBAC 规则不生效、日志里查不到路由删除记录。
-
iris-admin的permRoutes是带元数据的路由注册中心：含 HTTP 方法、角色白名单、中间件列表、描述字段 - 调用
admin.DeleteRoute(path, method)会自动触发log.Printf("iris-admin: delete %d router", len(dels)) - 新增路由必须走
admin.AddRoute()，它内部会安全调用对应Party的Reset()和重注册 - 漏掉这层封装，热重载就只是“能跑”，不是“可管、可审、可回滚”
调试时最容易被忽略的陷阱
热重载流程看似简单，但实际卡住的地方往往不在路由注册本身，而在上下文依赖和中间件状态。比如你重载了 /api/v2/users，但 handler 里用了全局未 reset 的缓存 map，或者中间件里 ctx.Values().Set() 的 key 在两次注册间不一致，结果行为漂移却无报错。
- 所有依赖外部状态（DB 连接池、Redis client、计数器）的 handler，必须确保重载后仍指向同一实例
- 中间件注册顺序不能混在重载逻辑里——
group.Use()应在Reset()后立即执行，且固定不变 - 不要在 handler 内部做
time.Sleep或阻塞 IO 来“模拟慢接口”测试重载，这会让 goroutine 卡住，掩盖真正的生命周期问题 - 最隐蔽的坑：重载后旧 handler 函数指针还在 GC 栈里残留，若它引用了已释放的资源（如 closed channel），panic 可能延迟几秒才爆发
