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 和字段索引：
立即学习“go语言免费学习笔记（深入）”；
var typeCache = map[reflect.Type][]reflect.StructField{}
func getCachedFields(t reflect.Type) []reflect.StructField {
if fs, ok := typeCache[t]; ok {
return fs
}
fs := make([]reflect.StructField, t.NumField())
for i := 0; i < t.NumField(); i++ {
fs[i] = t.Field(i)
}
typeCache[t] = fs
return fs
}
注意：reflect.Type 是可比较的，可用作 map key；但 reflect.Value 不行，别试图缓存它。
用 reflect.StructTag 解析自定义标签时，别忽略空格和引号
StructTag 是字符串，格式为 `key1:"value1" key2:"value2"`，但 Go 标准库的 tag.Get("json") 会自动 trim 空格并处理转义。手动解析时容易出错——比如用 strings.Split(tag, " ") 拆分，遇到 json:"user_id,omitempty" 就会断错。正确方式始终用 structField.Tag.Get("key")，它内部已做规范解析。若需提取多个子项（如 omitempty、string 等），再对返回值用 strings.Split 或正则；且注意：空 tag（``）返回空字符串，不是 nil。
一个常被忽略的细节：标签值里的双引号必须成对，且不能嵌套；Go 编译器不会报错，但 Tag.Get 会返回空字符串，导致逻辑静默失效。
