Go 的 reflect 包不支持直接运行时依赖注入，需基于 struct tag、CanSet、AssignableTo 等能力手动实现字段查找、类型匹配与赋值逻辑。
Go 语言标准库的 reflect 包本身不直接支持运行时依赖注入（DI），因为 Go 没有类、构造函数重载或注解机制，且编译期类型擦除彻底；所谓“反射用于 DI”，实际是框架在结构体标签（struct tag）、字段可设置性（CanSet）、类型匹配（AssignableTo）等反射能力基础上，手动实现依赖查找与赋值逻辑。
为什么不能直接用 reflect.New 做自动注入
常见误区是以为调用 reflect.New(typ) 就能“创建带注入的实例”——它只做内存分配和零值初始化，不触发任何依赖解析。真正需要的是：遍历结构体字段 → 判断是否标记为需注入（如 inject:"db"）→ 在容器中查找匹配类型的实例 → 调用 field.Set() 赋值。
-
reflect.ValueOf(obj).FieldByName("DB")必须是 exported 字段（首字母大写），否则CanSet()返回 false - 若字段是接口类型（如
DB *sql.DB），需确保容器中注册的是具体类型或满足该接口的实例 - 嵌套结构体字段不会被自动递归处理，必须显式展开或使用深度遍历逻辑
reflect.StructTag 解析字段注入标识
依赖注入框架（如 dig、wire、自研轻量容器）常通过结构体字段的 inject 或 autowire tag 控制注入行为。反射读取 tag 后，需手动解析键值，不能依赖通用语法（Go 不提供类似 Java 的 @Inject 元数据模型）。
type Service struct {
DB *sql.DB `inject:"default"`
Cache redis.Client `inject:"cache"`
}
- 用
field.Tag.Get("inject")获取原始字符串，再按需切分（如strings.SplitN(tag, ":", 2)） - 空 tag（
`inject`）和缺失 tag 应视为“不参与注入”，避免默认行为引发意外覆盖 - tag 值建议限制为 ASCII 字符，避免 URL 编码或空格导致解析失败
类型匹配时 AssignableTo 与 ConvertibleTo 的区别
注入过程中判断“容器中某个实例能否赋给目标字段”，关键在类型兼容性检查。错误地使用 ConvertibleTo 可能绕过接口约束，导致运行时 panic。
立即学习“go语言免费学习笔记（深入）”；
- 字段是接口类型（
type Storer interface{ Save() }），应检查instanceType.Implements(storerType)或instanceValue.Type().AssignableTo(fieldType) - 字段是具体指针类型（
*sql.DB），则必须严格匹配（instanceType == fieldType或instanceType.AssignableTo(fieldType)） -
ConvertibleTo允许底层类型相同但名称不同的类型互转（如type MyDB *sql.DB→*sql.DB），但 DI 场景中通常应禁止此类隐式转换，防止语义混淆
性能开销与初始化时机的权衡
每次构建对象都走一遍反射字段遍历 + tag 解析 + 类型匹配，会带来可观开销。生产环境应避免在高频路径（如 HTTP handler 内）反复调用注入逻辑。
- 推荐在应用启动时一次性完成依赖图构建（如
dig.Graph或自建map[reflect.Type]reflect.Value缓存） - 缓存 key 应基于
reflect.Type而非字符串（避免同名不同包类型冲突） - 若使用
reflect.Value.MethodByName调用初始化方法（如Init()），需确认该方法是 exported 且接收者为指针
反射只是工具，不是魔法。所有“自动注入”背后都是显式的类型查找、字段赋值和生命周期管理逻辑——漏掉 CanAddr() 检查、忽略接口实现验证、或在非指针接收者上尝试 Set()，都会让注入在运行时突然失败。
