Go需手写轻量DI容器以支持运行时动态注册和插件化场景，核心是用reflect.Type+Name作key、sync.Map缓存实例、Provide注册构造函数、GetOrBuild延迟初始化，并显式处理循环依赖与多实例区分。
Go 本身没有反射驱动的“开箱即用”依赖注入容器，但你可以用 reflect + sync.Map + 构造函数注册实现一个轻量、可控、无魔法的自定义 DI 框架——关键是别碰 interface{} 隐式绑定，也别学 Spring 做全自动扫描。
为什么不用第三方 DI 库（比如 wire 或 dig）？
如果你需要编译期确定依赖图、零反射、可调试性强，wire 是更安全的选择；但若你正开发一个插件化服务、需运行时动态注册组件（比如用户传入自定义 Handler 或 Repository），或想透彻理解 DI 容器的核心契约，自己写一个最小可行容器反而更直接。
- 第三方库往往隐藏了生命周期管理细节，出问题时堆栈难追（比如
dig的nil pointer dereference错误常指向内部 reflect 调用） -
wire不支持运行时注册，无法应对插件热加载场景 - 手写能强制你厘清：哪些类型必须单例？哪些需要每次 New？哪些依赖必须非空？
核心结构体怎么设计才不踩坑？
一个可用的容器至少要区分「构造逻辑」和「实例缓存」，且避免竞态。不要把所有东西塞进一个 map[interface{}]interface{} —— 类型擦除后无法做类型安全校验，panic 会发生在取值时而非注册时。
- 用
type Key struct { Type reflect.Type; Name string }作为 map key，支持同类型多实例（如*sql.DB和*ent.Client都是*sql.DB） - 缓存层用
sync.Map，但只存已初始化完成的实例；构造函数（func() interface{}）单独存在普通 map 中，避免sync.Map存闭包带来的 GC 压力 - 提供
GetOrBuild()而非简单Get()：首次调用才执行构造函数，后续直接返回缓存值 - 禁止在构造函数中调用
container.Get()，否则极易死锁或循环依赖——应在Provide()阶段就检查依赖图是否有环（可用拓扑排序）
如何安全地解析构造函数参数并自动注入？
这是最易出错的部分。Go 的函数签名是第一类值，可以用 reflect.TypeOf(fn).In(i) 拿到第 i 个参数类型，再查容器里有没有对应 Key。但要注意：
- 参数必须导出（首字母大写），否则
reflect无法访问其类型信息 - 不支持带命名返回值的函数（
func() (v T)），因reflect.Func的In()/Out()行为不稳定 - 如果参数是接口类型（如
io.Writer），必须显式注册该接口的具体实现，不能靠 “实现该接口的任意 struct” 自动匹配（Go 没有类型类） - 建议限制最多支持 5 个参数，超过则要求用户手动传参，避免隐式依赖失控
示例：注册一个依赖 *http.Client 和 Logger 的 service：
container.Provide(func(client *http.Client, logger Logger) *MyService {
return &MyService{client: client, logger: logger}
})
容器会在调用 Get[*MyService]() 时，自动查找已注册的 *http.Client 和 Logger 实例并传入。
什么时候必须手动管理生命周期？
DI 容器不等于资源管理器。数据库连接池、gRPC 连接、文件句柄等，必须由使用者明确控制 Close / Shutdown 时机——容器可以帮你调用 Close() 方法（如果类型实现了），但绝不能替你决定何时关闭。
- 注册时加一个可选的
OnStop(func())回调，统一收集 shutdown 逻辑 - 避免在
Get()返回的实例上做 defer —— 容器不知道谁在用它，也无法判断是否该释放 - HTTP handler 中注入的 request-scoped 对象（如
*http.Request）根本不能放进容器缓存，必须由 handler 函数自己构造并传递
真正容易被忽略的是：**类型名相同但语义不同的实例，必须用 Name 字段区分**。比如两个 *sql.DB，一个连 MySQL，一个连 PostgreSQL，光靠 reflect.Type 无法区分，硬塞进去会导致运行时覆盖或 panic。这个设计缺陷，只有在写测试用例模拟多数据源时才会暴露。
