反射在依赖注入中应避免热路径调用，初始化时缓存类型字段映射、注入前校验有效性、注册阶段严格类型检查，并用 reflect.New(typ).Elem() 替代手动取地址，以减少开销和 panic 风险。
反射在依赖注入中不是不能用，而是不能在热路径上反复调用；初始化阶段做一次完整注入是安全的，但每次请求都 reflect.ValueOf + FieldByName 就会明显拖慢吞吐。
避免在 Inject() 中重复解析结构体类型
每次调用 Inject 都执行 reflect.TypeOf(obj).Elem() 和遍历字段，相当于把编译期可知的结构信息硬生生搬到运行时查——既浪费 CPU，又触发额外内存分配。
- 缓存
reflect.Type到字段索引映射，例如用map[reflect.Type][]int存每个需注入字段的FieldByIndex路径 - 首次遇到某类型时解析并缓存，后续直接按索引取字段，跳过
FieldByName的字符串查找开销 - 注意：缓存键必须用
t = t.Elem()后的 struct 类型，否则*Service和Service会被视为不同键
别在字段赋值前漏掉 IsValid() 和 IsNil() 检查
reflect.Value.Interface() 在底层指针为 nil 时直接 panic，这在依赖未注册或构造失败时极易发生。错误不是出在“怎么注入”，而是没提前拦住非法状态。
- 对每个待注入字段值
v，必须先写if !v.IsValid() || v.IsNil() { continue } - 若字段是
*T类型，且容器里只注册了T（非指针），不能直接v.Set(newVal)，得用v.Set(reflect.ValueOf(&inst).Elem())构造可寻址指针 - 字段类型为接口时，
v.Kind() == reflect.Interface但v.IsNil()为 true，说明还没被赋值，此时应跳过而非强转
注册阶段就拒绝不合法的类型绑定
很多框架把类型校验拖到 Inject 时才做，导致 panic 出现在业务逻辑深处，堆栈难读、定位耗时。真正的优化是从注册入口就卡死问题。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
-
Register(instance interface{})内部应检查v := reflect.ValueOf(instance)是否v.IsValid()，且若为指针则!v.IsNil() - 禁止注册未导出字段的类型（如
type s struct { db *sql.DB }），因为反射无法写入，后续Inject必然失败 - 对接口注册（如
Register(new(MyRepoImpl))注册到MyRepo接口），需提前验证impl是否实现了该接口：v.Type().Implements(ifaceType)
用 reflect.New(typ).Elem() 替代 reflect.ValueOf(&T{})
手动构造 &T{} 再包进 reflect.ValueOf 看似简洁，实则多一次内存分配和逃逸分析干扰；而 reflect.New(typ).Elem() 是反射原生支持的零分配创建方式。
-
reflect.New(typ)返回reflect.Value类型的指针，.Elem()获取其指向的可设置值，全程不触发 GC 分配 - 对比：
reflect.ValueOf(&MyStruct{}).Elem()先 new 一个堆对象，再反射包装，两步开销 - 仅适用于 struct 类型；若需注入接口，仍要靠已注册的实现来
reflect.ValueOf(impl).Convert(ifaceType)（前提是底层类型兼容）
最易被忽略的是：字段标签（如 `inject:"db"`）本身不会带来性能问题，但用它做运行时 key 去查 map，就等于把类型匹配逻辑从编译期推到运行时——而 Go 的类型系统本就足够明确，真要用标签，也该只用于区分同类型的多个实例（如主从 DB），其余一律按类型自动匹配。
