反射调用与接口调用本质不同：前者是运行时动态解析，后者是编译期绑定itab查表跳转；反射不参与类型系统调度，无法替代接口实现，高频场景必须用接口。
反射 reflect.Value.Call 和接口方法调用，根本不是一回事
Go 的“多态”只有接口实现这一种正统路径；反射只是运行时操作值的工具，它不参与类型系统调度，也不触发接口动态派发。你用 reflect.Value.Call 调一个方法，跟直接写 obj.Method() 在底层走的是两条完全不同的指令流。
常见错误现象：panic: reflect: Call using zero Value 或调用后没效果——往往是因为忘了先用 reflect.Value.Addr() 获取可寻址值，或传参类型/数量不匹配，而接口调用不会出现这种 panic，失败只会在编译期报错。
- 接口方法调用：编译期绑定
itab，运行时查表跳转，开销极小（一次指针解引用 + 偏移计算） - 反射调用：要解析函数签名、逐个包装参数、检查可调用性、生成临时栈帧，慢一个数量级不止
- 反射无法绕过接口契约：即使结构体有某个方法，若没显式实现接口，
reflect.Value.MethodByName找不到它（除非用reflect.Value.Method索引序号）
接口动态派发靠 itab，不是 vtable
Go 没有 C++ 那种虚函数表（vtable），而是每个接口变量背后带一个 itab 结构体，里面存着具体类型的指针、接口类型的指针，以及方法地址数组。每次接口方法调用，本质是查这个 itab 里的函数指针再跳转。
使用场景：当你看到 interface{} 或自定义接口变量被传入函数并调用其方法时，背后就是 itab 在工作；但如果你用 reflect.TypeOf(x).Method(i) 去遍历，拿到的是反射对象，和运行时派发无关。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
itab是懒生成的：第一次把某类型赋给某接口时才构建，之后复用 - 空接口
interface{}的itab只存类型信息，不存方法——因为它没方法 - 两个不同接口（哪怕方法签名一样）会生成不同的
itab，不能共享
想模拟“动态多态”，优先用接口组合，别硬上反射
比如你要写一个插件系统，支持不同数据源（MySQL、Redis、HTTP），别一上来就用 reflect.Value.MethodByName("Fetch") 去调；而是定义 type DataSource interface { Fetch() ([]byte, error) }，让各实现注册进来——这样既类型安全，又快，还能被 IDE 跳转、静态分析覆盖。
容易踩的坑：有人用反射做“通用 handler”，结果所有实现都得加 func (x *T) Handle(...)，但漏写了指针接收者，导致反射能找着方法却调不了（因为非指针值不可寻址）；而接口方式下，编译器直接报错 T does not implement DataSource (Handle method has pointer receiver)。
- 反射适合一次性、低频、配置驱动的场景（如 ORM 字段映射、CLI 参数绑定）
- 高频调用路径（如 HTTP handler、数据处理 pipeline）必须用接口，否则 GC 压力和延迟都会明显上升
- 如果真要混合类型+动态行为，考虑用
map[string]func()或sync.Map缓存反射结果，但别在热路径反复reflect.ValueOf().MethodByName()
reflect.Kind() 和 reflect.Type.Kind() 不等于接口类型判断
很多人误以为用 reflect.TypeOf(x).Kind() == reflect.Struct 就能代替“是否实现了某接口”，这是错的。Kind 只描述底层数据形态（struct/map/slice 等），不包含方法集信息；接口实现与否，看的是类型的方法集是否包含接口要求的所有方法签名。
正确做法：用 if _, ok := x.(MyInterface); ok { ... } 类型断言，或者用 reflect.TypeOf(x).Implements(reflect.TypeOf((*MyInterface)(nil)).Elem().Type()) ——但后者性能差、难读，仅调试用。
-
reflect.Value.Kind()对接口变量返回Interface，对其底层值调Elem()后才看到真实Kind - 用
reflect.Value.CanInterface()判断能否转回原接口，比直接.Interface()更安全 - 注意：未导出字段在反射中可见，但无法通过接口暴露——接口只能约束导出方法
真正麻烦的地方在于，反射和接口各自有一套类型视图，混用时容易以为“看起来一样”就等价，其实它们在编译器眼里连内存布局都不共用。写的时候顺手，跑起来才发现 panic 或性能崩了。
