Go 的 IoC 容器本质是启动期一次性依赖组装工具，非运行时动态管理框架；须显式注册具体类型或接口、避免 interface{} 键、禁止 hot path 反射调用、同步 Resolve 优于异步 Get。
Go 语言没有内置 IoC 容器，所谓“反射实现的轻量级容器”，本质是手动控制依赖组装时机和方式，不是运行时动态管理对象生命周期的框架——别把它当 Spring 用，也别在 HTTP handler 每次调用里 Resolve。
注册依赖必须显式声明类型，不能靠反射自动推断
Go 的接口是隐式实现，reflect.Type 无法自动识别 “哪个 *sql.DB 满足 database/sql.ConnPool”。你得自己告诉容器：container.Register(<code>*sql.DB, db) 或 container.Register(<code>io.Writer, logger)。
- 注册键必须是具体类型（如
*sql.DB）或接口类型（如io.Reader），两者不可混用——*sql.DB和io.Writer是两个独立 key - 避免用
interface{}当注册键，Resolve 时完全无法匹配 - 一个 struct 实现多个接口，要分别注册：
container.Register(<code>io.Reader, r)、container.Register(<code>io.Closer, r) - 注册值必须非 nil；若构造函数返回
nil却没校验，后续Resolve直接 panic
Resolve 失败时只报 reflect: Call using zero Value，不提示缺啥依赖
当你调用 container.Resolve(<code>*Service)，而 Service 构造函数是 func(*DB, Cache) *Service，容器必须已注册 *DB 和 Cache 类型。缺一个，Resolve 就 panic，但错误信息不会说“缺 Cache”，只会抛底层反射错误。
- 检查注册顺序：先注册基础依赖（配置、日志），再注册上层服务
- 构造函数参数类型必须与注册类型完全一致（包括指针/值语义）
- 不要依赖“自动创建无参 struct”——有些容器支持，但一旦字段有未注册依赖，就静默失败或 panic
- 测试时可提前遍历所有注册类型，调用
Resolve做启动校验
别在 hot path 里用 reflect.Value.Call
每次 reflect.Value.Call 比直接函数调用慢 10–100 倍。如果你把 Resolve 放在每个 HTTP 请求处理中，性能会明显下滑。
立即学习“go语言免费学习笔记（深入）”；
- 只在启动阶段做一次依赖组装，比如
main()或服务初始化函数里调用Resolve - handler 层应接收已构造好的 service 实例，或用高阶函数传入构造逻辑：
http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { s := newService(); ... }) - 若真需要运行时动态 Resolve（如插件系统），缓存
reflect.Value而非每次都reflect.ValueOf(fn)
异步 Get 返回零值指针，没法区分“未初始化”和“就是零值”
像 Get(&v) 这种异步填充设计，返回的是指向零值的指针（如 &struct{}{}），而非 nil。客户端无法判断是容器还没 ready，还是业务逻辑本就该返回空结构。
- Go 没法返回一个“之后能被设为非 nil 的 nil 指针”——
reflect.Value不支持后期重绑定地址 - 可行替代：返回
chan interface{}或*sync.Once+ 显式Wait()，让调用方明确感知初始化状态 - 更务实的做法：放弃异步 Get，改用同步
Resolve+ 启动时集中初始化，避免状态歧义 - 如果必须延迟加载，用指针包装器加
atomic.Bool标记是否 ready，而不是靠反射塞值
真正难的不是写个能 Register 和 Resolve 的容器，而是守住边界：不在高频路径反射调用、不试图模拟运行时 AOP、不把初始化逻辑和业务逻辑混在一起。越早接受“Go 的 IoC 就是启动期的一次性组装”，越少掉坑。
