go反射虽可绕过编译期检查实现动态类型处理，但性能差、调试难、内存开销大，仅适用于编译期类型未知的必要场景；使用前须校验isvalid、caninterface和canset，且应缓存type与structfield避免热路径重复调用。
反射能绕过编译期类型检查，但不等于该用就用
Go 的反射（reflect 包）本质是运行时读取类型与值的元信息，它让代码能“动态处理未知结构”，比如通用序列化、配置绑定、ORM 字段映射。但它代价明确：性能下降 3–10 倍、编译器无法做类型校验、堆内存分配增多、调试困难。真正需要反射的场景其实很窄——不是“想写得灵活”，而是“必须处理编译期不可知的类型”。比如：json.Unmarshal 内部用反射解析任意 interface{}；又比如 CLI 工具把命令行参数自动注入到某个 struct 字段，而该 struct 类型在调用前才确定。
用 reflect.Value.Interface() 前先确认是否已解包
常见错误是连续调用 .Interface() 导致 panic：“call of reflect.Value.Interface on zero Value”。这通常发生在：对空指针解引用、对未导出字段直接取值、或误对 reflect.ValueOf(&x) 的结果再次取地址后调用 .Interface()。正确做法是分三步判断：
- 先用
v.IsValid()确保值非零 - 再用
v.CanInterface()判断是否允许转为 interface{}（例如未导出字段返回 false） - 最后才调用
v.Interface()；若需修改原值，必须确保v.CanSet()为 true，且原始变量本身是指针
示例：传入 struct{ Name string } 实例 x，reflect.ValueOf(x).FieldByName("Name").Interface() 会 panic，因为字段值不可寻址；必须传 &x，再用 .Elem().FieldByName("Name")。
避免在热路径中反复调用 reflect.TypeOf 和 reflect.ValueOf
每次调用这两个函数都会触发运行时类型查找和反射对象构建，开销不可忽视。如果某类结构体被高频反射（如 HTTP 请求体解析），应提前缓存 reflect.Type 和字段索引：
