Go反射不适合通用DI框架，因其无法动态生成类型、修改字段导出性或拦截构造过程，仅能做参数解析与实例缓存；真实项目应优先显式传递依赖。
为什么 Go 的反射不适合做通用依赖注入框架
Go 语言的反射能力有限，reflect 包无法在运行时修改结构体字段的可导出性、不能动态生成类型、也不支持方法重写或代理。这意味着你无法像 Spring 或 Python 的 injector 那样自动扫描包、按接口绑定实现、或拦截构造过程。所谓“基于反射的 DI 框架”，实际只是做了「构造函数参数解析 + 类型匹配 + 实例缓存」这一层，离“框架”距离很远——它更接近一个轻量级对象工厂。
reflect.TypeOf 和 reflect.ValueOf 怎么安全地解析构造函数参数
关键不是“能不能反射”，而是“怎么避免 panic”。常见错误包括：reflect.Value.Call 传入 nil 参数、对非函数类型调用 Call、或参数数量/类型不匹配导致崩溃。
- 必须先用
reflect.TypeOf(fn).Kind() == reflect.Func判断是否为函数 - 用
reflect.TypeOf(fn).NumIn()获取参数个数，再逐个检查reflect.TypeOf(fn).In(i)是否为指针或接口（否则无法注入） - 调用前确保每个
reflect.Value参数已通过reflect.New(t).Elem()或已有实例转换而来，不能直接传nil - 建议封装一层
CanInject(t reflect.Type) bool，过滤掉int、string、struct{}这类无法由容器提供的类型
示例：只允许注入指针或接口类型
func CanInject(t reflect.Type) bool {
if t.Kind() == reflect.Ptr || t.Kind() == reflect.Interface {
return true
}
return false
}
如何避免循环依赖和单例生命周期失控
反射本身不提供依赖图分析能力。一旦 A 依赖 B、B 又依赖 A，Build() 会无限递归直到栈溢出，且没有清晰错误提示。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 必须手动维护一个正在构建中的类型栈（
map[reflect.Type]bool），每次进入buildInstance前标记，返回前清除 - 检测到重复出现时立即 panic 并打印路径，例如：
"circular dependency: *db.Client → *service.UserService → *db.Client" - 单例（singleton）不能仅靠
sync.Once，因为不同构造函数可能产生同一类型的多个实例（比如func() *Client和func(log Logger) *Client应视为不同签名） - 缓存 key 必须是
reflect.Type+ 构造函数的reflect.Value地址（fn.Pointer()），而非仅类型
真实项目里该不该自己写这套逻辑
大多数 Go 项目不需要运行时 DI。标准做法是显式传递依赖：service.NewUserService(repo, logger)。这比反射更易测试、调试和阅读。只有当模块边界极多、且构造链深度 > 5 层（如 CLI 工具插件系统）时，才值得引入最小化反射注入——但此时也应限制为「只解析顶层构造函数，不递归解析其依赖的依赖」。
最容易被忽略的一点：Go 编译器无法内联反射调用，所有 reflect.Value.Call 都是运行时开销，且逃逸分析失效，容易导致意外堆分配。上线前务必用 go tool compile -gcflags="-m" 看关键路径是否逃逸。
