go反射不能真正“替换”接口方法，因方法集编译期绑定、接口无运行时方法表劫持能力；所谓mock实为用reflect分析接口后生成新结构体并手动实现，或通过reflect.makefunc构造函数值绑定到代理字段。
Go反射不能直接“替换”方法，但能动态构造满足接口的新对象——这是所有基于反射的Mock生成工具（包括mockgen）的本质。
为什么用 reflect.Value.Call 无法真正 Mock 接口方法
常见误解是：既然 reflect.Value.Call 能调用任意函数，那就能“劫持”接口方法调用。事实并非如此。
- 接口变量本身不包含可修改的方法表；
reflect.ValueOf(interface{}).Method(i)只能读取已绑定的方法，不能重写或注入逻辑 - 调用
reflect.Value.Call是对某个具体reflect.Value（比如一个函数值）的操作，不是对接口变量行为的全局拦截 - Go 的方法集在编译期绑定，运行时无法改变已有变量的底层方法实现
- 所谓“反射式 Mock”，实际是用反射分析接口定义，再生成一个全新结构体类型，手动实现该接口，并把行为控制权交给测试代码
mockgen 的 reflect 模式到底做了什么
当你执行 mockgen database/sql/driver Conn,Driver，它并不是在运行时用 reflect 包去“抓取”当前进程里的接口实例，而是：
- 构建一个临时程序，
import目标包（如database/sql/driver），然后用reflect.TypeOf((*Conn)(nil)).Elem()获取接口类型信息 - 遍历
reflect.Type.Methods()，提取每个方法的名称、参数类型、返回类型、是否导出等元数据 - 用
text/template或字符串拼接，生成一个新 Go 文件，里面定义类似MockConn struct { ctrl *gomock.Controller }和对应方法实现 - 生成的
Call、Return、Times等逻辑，全部基于gomock.Controller的状态机管理，和原始接口无运行时耦合
手动用 reflect 实现轻量 Mock 的可行边界
真正在测试中手写反射逻辑做 Mock，只适合极简场景，比如单方法、无泛型、无嵌套 error 返回的接口。例如：
- 目标接口只有一个方法：
type Getter interface{ Get(key string) (string, error) } - 你用
reflect.StructOf动态构造结构体类型，再用reflect.New创建实例，最后用reflect.MakeFunc绑定闭包到方法字段——但这要求你提前知道方法签名，且无法支持指针接收者自动适配 - 更现实的做法是：用反射读取接口定义 → 生成一个带字段的 struct（如
GetFunc func(string) (string, error)）→ 手动实现接口方法，转发到该字段 - 这种模式见于
testify/mock的简易 Mock 结构体，但它不依赖reflect生成代码，而是靠开发者显式定义字段和转发逻辑
容易被忽略的关键点：接口必须导出，且 mockgen 不解析未引用的嵌套类型
如果你的接口方法返回了一个未在当前包 import 的自定义错误类型，或者参数里用了未导出的 struct 字段，mockgen -package 模式会静默失败或生成编译不过的代码。
-
mockgen的 reflect 模式依赖go/types+reflect配合解析，但它不会主动加载未被 import 的包 —— 即使那些类型在接口签名里出现 - 若接口定义在
internal/目录下，mockgen -package无法访问（Go 规则限制），必须改用-source模式 - 泛型接口（如
type Repository[T any] interface{ Save(T) error }）在旧版 mockgen（v1.6 之前）不支持，需确认版本是否含golang.org/x/exp/constraints兼容逻辑
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
