reflect.value.call panic 的根本原因是传入了零值 reflect.value，常见于 nil 接口、类型不匹配或未正确解指针；需确保对象非 nil、类型一致、方法导出，并用 elem() 获取底层实现。
为什么 reflect.Value.Call 会 panic “call of reflect.Value.Call on zero Value”
这是 Mock 框架里最常卡住人的点：想用反射调用一个被替换的方法，但传进去的 reflect.Value 其实是空的。根本原因不是你没写对函数名，而是没正确从接口或结构体里“取出”那个方法值。
常见错误场景：你 mock 了一个接口 *MyService，然后试图用 reflect.ValueOf(obj).MethodByName("DoWork") 获取方法，但 obj 是 nil 或者类型不对（比如传了 interface{} 却没断言成具体类型）。
- 确保目标对象非 nil，且类型和接口定义一致；
reflect.ValueOf前先做类型检查，比如if v := reflect.ValueOf(obj); v.Kind() == reflect.Ptr && !v.IsNil() - 接口方法必须导出（首字母大写），否则
MethodByName返回零值 - 如果 mock 对象是接口类型，要先用
reflect.ValueOf(&obj).Elem()解一层指针，再取方法，否则拿到的是接口头，不是底层实现
如何用 reflect.New + reflect.Value.SetMapIndex 动态构造 map 类型 mock 返回值
有些服务方法返回 map[string]interface{} 或嵌套 map，硬写 struct 不现实，又不想依赖第三方 mock 工具生成器——这时得靠反射现场造。
关键不是“创建 map”，而是“让 map 能被后续反射调用正确读取”。直接 reflect.MakeMap 出来的 map 是只读的，没法塞进 struct 字段或作为函数返回值被正常解包。
立即学习“go语言免费学习笔记（深入）”；
- 用
reflect.New(reflect.TypeOf(map[string]interface{}{}).Elem())创建可寻址的 map 实例 - 调用
.Elem()得到 map 的reflect.Value，再用SetMapIndex插入键值对，比如：mv.SetMapIndex(reflect.ValueOf("status"), reflect.ValueOf("ok")) - 注意 key 类型必须严格匹配 map 定义，
string和reflect.TypeOf("x").Kind()必须是reflect.String，否则 panic “invalid map key”
reflect.StructTag 解析失败导致 mock 行为绑定错位
不少 Mock 框架靠 struct tag（比如 `mock:"DoWork=return(200, err)"`）来声明伪造逻辑。一旦 tag 解析出错，行为就完全不生效，还查不出原因。
问题往往不在正则或语法，而在 Go 的 tag 规范本身：tag 字符串必须是双引号包裹的纯字符串字面量，不能换行、不能有未转义的双引号，且 key 必须小写。
- 用
structField.Tag.Get("mock")取值后，先检查是否为空；空不代表没写 tag，可能是格式非法被编译器静默丢弃 - 别手动拼接 tag 字符串，用
reflect.StructTag的Get方法，它会自动处理空格和引号剥离 - 如果 tag 值含括号或逗号（如
return(1, "msg")），解析时要用配对计数，不能简单strings.Split，否则嵌套结构直接切碎
性能陷阱：reflect.Value.Convert 在高频 mock 调用中引发 GC 压力
为了兼容不同参数类型，有些 mock 逻辑会在每次调用前做 Convert，比如把 reflect.ValueOf(int64(1)) 强转成 int。这看着没问题，但在每秒上千次的测试循环里，会显著拖慢测试执行，甚至触发频繁 GC。
根本原因是 Convert 会分配新 reflect.Value，而 reflect.Value 内部持有指向原始数据的指针+类型信息，频繁创建等于在堆上反复打洞。
- 优先复用已有的
reflect.Value，比如提前缓存参数模板，用.Set替代.Convert赋值 - 能用类型断言就不用反射转换：比如参数确定是
int，就用v.Interface().(int)，比v.Convert(reflect.TypeOf(0).Type).Int()快 3–5 倍 - 如果必须 Convert，确保目标类型已在
reflect.TypeOf中预热过，避免 runtime.typehash 反复计算
反射不是黑魔法，它是把双刃剑：能绕过类型系统，也会把类型系统的保护一并砍掉。Mock 里最危险的不是调用失败，而是调用成功了，但行为和真实逻辑差了一层间接性——那才是最难 debug 的地方。
