Go中不推荐用反射构建Mock对象，因其易失控、难调试、掩盖设计问题；应优先手动实现接口，仅在泛化断言库等极少数场景才考虑反射介入。
Go 里用反射构建 Mock 对象，不是常规推荐路径——它容易失控、难调试、掩盖设计问题。真要 mock，优先手动实现接口；只有在极少数需动态行为注入（比如泛化断言库、DSL 测试辅助）时，才考虑反射介入。
为什么 reflect.MakeFunc 不该用于日常 Mock
很多人看到 reflect.MakeFunc 能“动态生成函数”，就想着拿它包装接口方法，绕过手写结构体。但实际踩坑密集：
-
reflect.MakeFunc返回的函数无法被 IDE 跳转、无类型提示、调用栈丢失原始上下文 - 它不能自动满足接口——你得再用
reflect.New构造结构体，再用reflect.Value.MethodByName替换方法，整套流程极易因不可寻址 panic - 一旦被测代码里有类型断言（如
v, ok := svc.(interface{ Close() })），反射构造的对象大概率失败，因为底层类型不匹配 - 性能上虽单次开销小，但在千级测试中反复反射解析方法签名，会拖慢 test 启动 20–50ms
什么时候必须用反射？mockgen 和 testify/mock 的底层依赖
真正需要反射的场景，是工具链本身，不是你的测试代码：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
mockgen -package=xxx -interface=YYY在反射模式下，靠reflect.TypeOf((*YourInterface)(nil)).Elem().Method(i)提取方法名、参数、返回值，才能生成正确 mock 结构体 -
testify/mock的On("MethodName", arg1, arg2).Return(...)内部用reflect.ValueOf(fn).Call()拦截调用，再比对reflect.TypeOf(arg1)和传入参数是否一致——这也是它严格区分int和int32的根源 - 自定义测试 DSL（如支持
Test(t *testing.T, db *MockDB)）必须用reflect.TypeOf(fn).In(i)解析参数类型，再从全局 registry 匹配实例
reflect.ValueOf(t).MethodByName("Errorf") 为什么会 panic
这不是 mock 专用问题，而是反射调用通用陷阱：
立即学习“go语言免费学习笔记（深入）”；
-
t是*testing.T，但reflect.ValueOf(t)返回的是不可寻址副本，而MethodByName要求接收者可寻址才能调用 - 正确写法是
reflect.ValueOf(t).MethodByName("Errorf").Call([]reflect.Value{...})——前提是t本身是指针且未被复制；更稳妥的是直接用t.Errorf，根本不需要反射 - 常见错误现象：
panic: reflect: call of MethodByName on zero Value，往往是因为你传了 nil 接口或未初始化的 struct 字段 - 如果你在 mock 工具里看到类似逻辑，说明它在做测试辅助分发（比如封装 assert），而不是帮你 mock 业务依赖
最常被忽略的一点：反射 mock 的对象无法被 go vet 或静态分析工具校验是否真正实现了接口——它只在运行时暴露问题。手动结构体哪怕写错一个方法签名，编译期就报错，这才是 Go 的安全边界。
