air 不需要反射，因其仅通过监听文件变化、触发编译、重启进程实现热重载，全程不介入运行时类型操作；反射在重启后全部重建，二者本质独立。
air 本身不依赖 reflect，也不参与运行时类型操作；热重载与反射在 Go 中是两条独立路径——一个管「编译+进程重启」，一个管「运行时类型自省」。强行结合不仅无益，反而引入隐性风险。
为什么 air 不需要反射
air 的核心行为是监听文件变化 → 触发 go build → 杀掉旧进程 → 启动新二进制。整个过程发生在进程外部，不侵入你的代码逻辑，也不接触任何 interface{} 或 reflect.Value。
- 它不解析 Go 源码 AST，不扫描结构体字段，不调用
reflect.TypeOf - 它不修改内存中的变量，不调用
Value.Set，也不依赖CanSet() - 它甚至不知道你代码里有没有用
plugin或reflect—— 它只认.go文件和退出码
哪些场景看似“结合”，实则只是共存
你在用 air 开发一个基于反射的配置加载器？没问题。但要注意：
-
air重启后，所有reflect.Value实例都被销毁，新进程从头初始化 - 如果你在
init()里用reflect扫描 struct 标签注册 handler，每次重启都重新执行一遍 —— 这不是“热重载反射”，只是反射代码被重复加载 - 若你试图在运行中用
plugin.Open动态加载新模块，air无法感知该插件是否更新；必须手动触发plugin.Close+ 重新Open，否则旧符号仍驻留内存
reflect 在热重载环境下的典型陷阱
反射本身不关心进程生命周期，但开发者容易忽略状态残留：
- 全局 map 缓存了
reflect.Type→ 重启后缓存失效，但若误以为跨进程有效，会 panic - 用
reflect.ValueOf(&x).Elem()修改值 →air重启后x回到初始值，之前修改全丢，别指望“热保留” - 通过反射注册的 HTTP handler 函数指针 → 新进程里地址不同，旧注册表（如有）若未清空，可能 panic 或静默失败
真正要警惕的，不是怎么让反射“配合”热重载，而是别把进程级重启误解为运行时状态延续 —— air 没有 HMR（Hot Module Replacement），Go 也没有真正的 runtime 类型热替换。所有“热”都止于进程边界。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
