Iris MVC 不支持热重载，因其基于静态编译的 Go 语言，所有路由、依赖注入和控制器注册均在编译期固化；需借助 air 等工具实现文件监听→自动构建→进程重启的开发闭环。
Iris 的 MVC 本身不支持热重载 —— 它是编译型 Go 框架，没有运行时类加载或模块热替换机制。 你改了 controller 或 model，必须重新编译二进制并重启进程。所谓“Iris MVC 热重载”实际是开发流程层面的自动化补救，不是框架原生能力。
为什么 iris-mvc 无法像 Node.js 或 Python 框架那样热重载
Go 是静态编译语言，所有类型、方法绑定、路由注册都在编译期固化。Iris 的 mvc.Application 在 app.Run() 前就完成了控制器方法扫描、依赖注入和路由注册（通过 BeforeActivation 和反射），这些结构体和函数指针一旦写入二进制，运行时不可修改。
常见误解是以为 mvc.New(...).Handle(...) 是动态注册 —— 实际上它只是在启动前构造好路由表，最终仍交由 router.APIBuilder 编译进内存树（radix tree），没有运行时注册 API。
因此，以下操作不会触发热重载：
- 修改
Get()方法体内容后不重启进程 - 增删
BeforeActivation中的b.Handle()调用 - 改动
app.Register()注入的 service 实例
可行的开发期热重载方案（基于文件监听 + 自动构建）
真正提升效率的方式是绕过框架限制，在进程外建立“改代码 → 重编译 → 重启服务”的闭环。推荐组合：air（最轻量）或 reflex（更灵活）。
以 air 为例（需项目根目录有 .air.toml）：
[build] cmd = "go build -o ./app ." bin = "./app" include_ext = ["go", "tpl", "html", "json"] exclude_dir = ["vendor", "node_modules", ".git"] <p>[watch]</p><h1>监听 controller/ 和 mvc 相关路径变更</h1><p>paths = ["./controllers", "./models", "./main.go"]
启动命令：air。它会在检测到 controllers/ 下任意 .go 文件变化时自动执行 go build 并 kill+restart 进程。
注意几个关键点：
-
include_ext必须包含html和tpl（如果用了 Iris 的 view 渲染） -
paths要覆盖所有 MVC 组件所在目录，比如./mvc或./handlers，不能只写./main.go - 若使用
app.Register()注入全局依赖（如 DB 连接），确保初始化逻辑可重复执行（避免多次sql.Open导致连接泄漏）
热重载时 MVC 特有的坑：BeforeActivation 和依赖注入失效
每次重启进程，BeforeActivation 回调会重新执行，但开发者容易忽略两点：
- 中间件重复注册：比如在
BeforeActivation里写了b.Router().Use(myLogger)，而主程序又在app.Use()注册了一次 —— 重启后变成双倍日志 - 依赖未清理：若在
BeforeActivation中用b.Dependencies().Add(&MyService{})注入单例，但MyService内部持有未关闭的资源（如文件句柄、长连接），多次重启可能耗尽系统资源 - 路由冲突：多个
mvc.Application共享同一Party路径前缀，且都调用Handle()，重启后可能因初始化顺序导致部分路由被覆盖（无报错，但请求 404）
验证方式：启动后 curl 一次 /debug/pprof/ 下的路由，再改 controller 保存，看 air 是否成功重启，以及 app.Get("/health") 是否仍响应 —— 这能快速确认 MVC 初始化链没崩。
真正需要关注的不是“怎么让 Iris 支持热重载”，而是“如何让每次重启足够快、副作用可控”。编译速度、依赖初始化幂等性、路由注册的确定性，比幻想框架支持运行时 reload 更实在。
