反射不是接口替代品，二者职责不同：接口用于编译期抽象与多态，反射用于运行时动态操作；应优先定义明确接口而非滥用interface{}和反射。
反射不是接口的替代品，它和接口在 Go 里承担完全不同的职责：接口用于编译期抽象与多态，反射用于运行时动态操作。强行用反射“模拟”接口行为，只会让代码不可读、难测试、易出错。
什么时候该用 interface{} 而不是 reflect.Value
绝大多数需要“泛型”或“松耦合”的场景，都应该优先定义明确的接口，而不是传 interface{} 再用反射拆解。
- 比如序列化函数，应接收
json.Marshaler接口，而非interface{}后用reflect.TypeOf判断字段是否导出 - 比如插件系统，应约定
Plugin接口（含Init()、Run()），而不是靠反射查找叫Run的方法 -
interface{}只应在真正无法预知类型且无更好抽象时使用（如fmt.Printf参数），之后也应尽快转为具体类型或接口，避免一路反射下去
reflect.Value.Call 调用方法前必须检查可调用性
直接对任意 reflect.Value 调用 .Call() 是常见 panic 来源，尤其当值是未取地址的 struct 字段或非导出方法时。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 调用前必须用
v.CanInterface()和v.Kind() == reflect.Func初筛 - 若目标是结构体方法，需确保
v来自指针（reflect.ValueOf(&obj)），否则MethodByName返回的reflect.Value不可调用 - 错误示例：
reflect.ValueOf(obj).MethodByName("Foo").Call([]reflect.Value{})—— 即使Foo是导出方法，obj非指针也会导致 panic
反射 + 接口组合的合理边界：仅用于“桥接层”
真正需要反射配合接口的地方，往往只存在于框架底层的适配逻辑中，比如 ORM 映射、RPC 参数解包、配置绑定等——这些层的目标是把外部数据/协议，安全地映射到已定义的接口或结构体上。
立即学习“go语言免费学习笔记（深入）”；
- 例如，将 map[string]interface{} 绑定到实现了
Setter接口的 struct：先用反射遍历字段名，再调用对应SetXxx方法（前提是该方法存在且签名匹配） - 关键约束：反射逻辑必须封装在独立函数内，输入是明确接口（如
BindingTarget），输出仍是该接口；业务层不感知反射 - 禁止在业务逻辑里写
if v.Kind() == reflect.Struct { ... }这类分支——这说明抽象缺失，该补接口了
最常被忽略的一点：反射带来的性能开销和类型安全丢失，无法靠文档或注释弥补。一旦某个模块开始大量依赖 reflect.Value.Interface() 回退到空接口，就说明它的契约正在瓦解——这时候该做的不是优化反射，而是重新设计那部分接口。
