Go 无内置 IoC 容器，所谓“反射实现”是手动轻量级依赖解析，仅解决初始化问题，不支持运行时替换、AOP 或自动销毁；注册需显式声明类型，避免空接口、循环依赖与 hot path 反射调用。
Go 里没有内置 IoC 容器，别被“反射+依赖注入”包装误导
Go 语言本身不提供类似 Spring 或 .NET 的 IoC 容器机制。所谓“用反射构建依赖容器”，本质是手动实现一套轻量级依赖解析逻辑，不是语言特性，也不进标准库。它解决的只是「谁来 new 对象、谁来传依赖」这个初始化问题，不是运行时动态替换行为。
常见错误现象：panic: reflect: Call using zero Value、interface{} is nil、构造函数返回 nil 却没校验、循环依赖导致栈溢出。
- 使用场景：中等规模 CLI 工具、内部服务启动阶段依赖组装（如配置 → 日志 → 数据库 → HTTP Server）
- 不适合场景：高频创建/销毁对象（如每个 HTTP 请求都走一遍容器 Resolve）、需要 AOP 或拦截器的业务逻辑
- 反射开销真实存在：每次
reflect.Value.Call比直接调用慢 10–100 倍，别在 hot path 里用
注册依赖时必须显式声明类型，不能靠反射自动推断
Go 的接口是隐式实现，但容器无法靠 reflect.Type 自动识别 “哪个 struct 满足哪个 interface”。你得告诉它：“这个 *sql.DB 就是 database/sql.DB 的实现”，否则 Resolve 时会失败。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 注册用具体类型（如
*sql.DB）或接口类型（如io.Writer），但两者不能混用——container.Register(<code>*sql.DB, db) 和container.Register(<code>io.Writer, db) 是两个独立键 - 避免用空接口
interface{}当注册键，会导致 Resolve 时无法匹配 - 如果一个 struct 实现多个接口，要分别注册：
container.Register(<code>Reader, r); container.Register(Closer, r)
构造函数参数必须可被容器满足，否则 Resolve 直接 panic
当你注册一个结构体 Service，它的构造函数是 func(NewDB() *DB, NewCache() Cache) *Service，那容器必须已注册 *DB 和 Cache 类型——缺一个，Resolve(<code>*Service) 就 panic，不会提示“缺 Cache”，只报 reflect: Call using zero Value。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
容易踩的坑：
- 参数顺序敏感：注册了
Cache但构造函数写成func(*DB, io.Writer)，而你只注册了Cache，不匹配 - 指针 vs 值类型：注册的是
Cache，但构造函数要*Cache，不兼容 - 未导出字段无法被反射设值，别指望容器帮你填
db *sql.DB这种私有字段——它只处理构造函数参数
别把初始化逻辑全塞进容器，配置和生命周期管理得自己兜底
容器只管“给什么类型就返回什么实例”，它不负责 Close()、重试、健康检查、热更新。比如你注册了一个 *redis.Client，容器不会在进程退出前调用 client.Close()。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 数据库、缓存、HTTP 客户端这类资源型依赖，应在
main()或启动函数里显式关闭，别依赖容器“销毁钩子”（多数手写容器压根没这功能） - 配置应早于容器初始化完成，比如先读
config.yaml，再把Config实例注册进去；别让构造函数再去读文件或环境变量 - 若需单例 + 延迟初始化（如第一次 Resolve 才创建 DB），要在构造函数里加锁，否则并发 Resolve 可能创建多个实例
最常被忽略的一点：容器本身也是个依赖。如果你把它塞进某个 service 的字段里，又让 service 参与容器初始化，很容易绕成循环引用——这时候该砍掉容器，改用显式传参。事情说清了就结束
