Go语言DI容器本质是注册表加反射调用，核心在于可控延迟绑定；reflect.Value.Interface() panic源于未校验nil指针；dig严格按类型精确匹配，指针/值、包路径差异均导致失败；推荐用reflect.Type作key而非字符串；手动DI通常优于运行时框架。
Go 语言里没有“自动扫描包”或“运行时注解解析”的依赖注入容器，所谓框架级 DI 容器，本质是注册表 + 反射调用的组合，核心不在“自动”，而在“可控地延迟绑定”。手写容易在 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() - 常见于结构体字段反射赋值前没做非空校验，或容器里压根没注册该类型实例却强行解析
dig 中类型匹配为何严格到指针/值都算不同类型
Dig 在 paramList.BuildList 阶段严格按参数类型查找提供者，哪怕只差一个 * 都找不到。它不转换、不推导，只精确匹配。
- 注册了
func() Logger（值类型），但Invoke函数写成func(l *Logger)→ 找不到提供者 - 注册了
func() *sql.DB，却在Invoke中写func(db *database.DB)→ 包路径不同，类型不等价 - 用了
dig.In包装参数，但结构体字段没导出（小写开头）→panic: cannot set unexported field
注册表该用 reflect.Type 还是字符串作 key
用 map[reflect.Type]interface{} 存实例最可靠。Go 中类型是第一公民，reflect.TypeOf((*sql.DB)(nil)).Elem() 和 reflect.TypeOf(&someDB).Elem() 能精确对齐；而字符串 key（如 "logger"）无法区分泛型实例 Repository[User] 和 Repository[Order]。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 泛型结构体字段的
StructField.Type是实例化后的完整类型（如Repository[User]），可直接用于 map 查找 - 别依赖 struct tag（如
inject:"logger"）做主匹配逻辑，tag 值是字符串，而真实依赖是类型；tag 只适合做命名覆盖（比如同类型多个实例时指定别名） - 导出字段才能被反射访问：结构体中
Repo UserRepository可以，repo UserRepository不行（v.Field(i).IsValid()返回 false）
手动 DI 比框架更值得优先考虑的场景
多数小到中型项目根本不需要运行时 DI 框架。wire 是代码生成，dig 是运行时反射，两者都增加了构建复杂度和调试成本。
- wire 要写
wire.go、加//+build wireinject标签、跑wire gen，改个依赖就得重生成 - dig 的错误信息是运行时 panic，比如
missing type *http.Client，但你根本不知道哪层调用链漏传了 - 接口没定义清楚时，DI 容器反而掩盖设计缺陷：本该拆成两个接口的，硬塞进一个 struct 里靠 DI “凑活用”
- 真正该用框架的信号是：依赖树深、交叉多、且手动
New开始重复粘贴——否则就从main函数开始串起依赖
复杂点不在“怎么注入”，而在“怎么确保类型对齐、字段可写、nil 不 panic”。这些细节一旦漏掉，运行时崩得无声无息，比编译报错更难定位。
