go依赖注入容器核心是可控延迟绑定，需严格校验reflect.value有效性、类型精确匹配及导出字段访问，泛型和并发场景下类型安全与生命周期管理尤为关键。
Go 语言没有运行时注解或自动扫描机制，所谓“框架级依赖注入容器”本质上是注册表 + 反射调用的组合，核心不在于“自动”，而在于“可控地延迟绑定”。直接手写反射容器容易在 reflect.Value.Interface() 处 panic，或因类型匹配失败静默跳过依赖。
为什么 reflect.Value.Interface() 会 panic
这不是 bug，是 Go 反射的明确限制：当 reflect.Value 底层持有一个未初始化的 nil 指针（比如 *sql.DB 字段值为 nil），直接调用 .Interface() 就会触发 invalid memory address or nil pointer dereference。
- 必须先检查
v.IsValid() && !v.IsNil()，再调用v.Interface() - 若字段是
*T类型，且你打算用v.Elem()取实际值，得先确认v.Kind() == reflect.Ptr && !v.IsNil() - 常见于结构体字段反射赋值前没做非空校验，或容器里压根没注册该类型实例却强行解析
构造函数参数自动匹配的陷阱
DI 容器要调用 NewService(*Repository, *Logger)，就得把已注册的 *Repository 和 *Logger 实例按顺序塞进 reflect.Value.Call() 的参数切片。错一位、类型不完全一致、值/指针混用，都会 panic。
- 函数签名里的每个参数，必须严格匹配注册实例的类型——
*sql.DB≠sql.DB≠driver.Conn - 接口类型注册时，要用具体实现的指针类型去查，比如注册了
MapTo(&db, (*sql.DB)(nil))，查找时也得用(*sql.DB)(nil)作 key，不能只传sql.DB - 别依赖 struct tag（如
`inject:"logger"`）做主匹配逻辑，tag 值是字符串，而真实依赖是类型；tag 只适合做命名覆盖（比如同类型多个实例时指定别名）
注册表设计：类型作为 key 才可靠
用 map[reflect.Type]interface{} 存实例最直接。Go 中类型是第一公民，reflect.TypeOf((*sql.DB)(nil)).Elem() 和 reflect.TypeOf(&someDB).Elem() 能精确对齐；而字符串 key（如 "logger"）无法区分泛型实例 Repository[User] 和 Repository[Order]。
- 导出字段才能被反射访问：结构体中
Repo UserRepository可以，repo UserRepository不行（v.Field(i).IsValid()返回 false） - 泛型结构体字段的
StructField.Type是实例化后的完整类型（如Repository[User]），可直接用于 map 查找，无需手动解析类型参数 - 单例缓存建议放在注册表同一层，避免每次
Get()都新建；但注意并发读写需加锁，或用sync.Map
真正难的不是“怎么把值塞进去”，而是“怎么确保塞进去的值，在调用那一刻确实是可用的、类型精确匹配的、生命周期可控的”。很多 DIY 容器在测试环境跑通，一到多 goroutine 并发或复杂泛型嵌套就暴露问题——类型擦除、指针层级错乱、未导出字段静默忽略，这些细节比语法更决定成败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
