reflect.value.call不能直接传struct字段值，因字段在非指针接收时是不可寻址的只读副本，需用addr()获取地址且确保struct实例本身可寻址。
为什么 reflect.Value.Call 不能直接传 struct 字段值？
因为 Go 反射要求被调用函数的参数必须是可寻址的（addressable），而 struct 字段在非指针接收时是只读副本。常见错误是把 struct{Dep *MyDep} 的 Dep 字段直接塞进 reflect.Value.Call，结果 panic：reflect: Call using zero Value 或 call of reflect.Value.Call on zero Value。
实操建议：
- 注入容器内部必须统一用
reflect.Value.Addr()获取字段地址（前提是该字段所属 struct 实例本身可寻址） - 构造依赖实例时优先返回指针（
&MyDep{}），避免后续反复Addr()失败 - 检查字段是否导出：未导出字段无法通过反射赋值，
reflect.Value.CanSet()会返回 false
如何安全地从 reflect.Type 推导构造函数签名？
依赖注入的核心是自动匹配类型与构造函数。不能硬编码函数名，得靠类型推导——比如发现需要 *sql.DB，就去找参数为 *sql.Config、返回 *sql.DB, error 的函数。
实操建议：
- 用
t.Kind() == reflect.Func过滤出函数类型，再用t.NumIn()和t.NumOut()检查入参和返回值数量 - 对每个入参调用
t.In(i).AssignableTo(targetType)判断是否兼容（注意：不能用==，因接口/指针可能不同但可赋值） - 忽略带
context.Context的第一个参数（常见于 http handler 风格函数），需手动跳过而非报错
container.Resolve(&v) 为什么会 panic “cannot set unaddressable value”？
这是最常踩的坑：用户传入一个栈上变量如 var svc MyService，然后调用 c.Resolve(&svc)，但容器内部误用了 reflect.ValueOf(svc) 而非 reflect.ValueOf(&svc).Elem()，导致拿到的是不可寻址的副本。
实操建议：
- Resolve 方法签名必须接收
interface{}，并在开头强制转成reflect.Value后立刻检查.CanAddr() - 若不可寻址，直接返回 error，不要尝试
.Addr()—— 它对非地址值会 panic - 典型修复写法：
v := reflect.ValueOf(ptr); if v.Kind() == reflect.Ptr { v = v.Elem() }; if !v.CanSet() { return errors.New("target not addressable") }
循环依赖检测为何不能只靠 map[string]bool？
仅记录类型名（如 "*db.Client"）会导致误判：两个不同包里同名类型（pkg1.Client 和 pkg2.Client）会被当成同一个，或泛型实例化后类型名相同但实际不等（map[string]int vs map[string]float64）。
实操建议：
- 用
reflect.Type.String()不可靠；改用reflect.Type.PkgPath() + reflect.Type.Name()拼接，再加reflect.Type.String()做 fallback - 更稳妥的是维护一个
map[uintptr]bool，key 是reflect.Type.UnsafeType()返回的地址（唯一且稳定） - 检测时机必须在
resolve函数入口 push，在 defer 中 pop，否则 defer 执行顺序会导致漏检
泛型类型、嵌套指针、接口实现体这些边界情况，光靠名字匹配一定会翻车。真正健壮的容器得把类型元数据当黑盒处理，而不是字符串解析。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
