reflect.TypeOf() 返回 reflect.Type 而非原始类型，因 interface{} 参数擦除类型信息；它仅提供只读结构描述，不能直接赋值或断言；需配合 reflect.ValueOf().Interface() 还原值，且仅导出字段可见。
Go 的 reflect 包不是用来“动态创建类型”或“绕过类型系统”的，它只在运行时读取已知类型的结构信息——如果你期望像 Python 那样自由地 new 任意类型、调用任意方法，会踩坑。
为什么 reflect.TypeOf() 返回的是 reflect.Type 而不是原始类型？
reflec 接收一个 interface{}，擦除了原始类型；它返回的 
t.TypeOf()reflect.Type 是对底层类型的只读描述，不等价于原类型本身。常见误解是以为能直接用它做类型断言或赋值。
- 传入
int(42)→reflect.TypeOf()返回描述int的reflect.Type，但你不能用这个对象当int用 - 若想还原值，必须配合
reflect.ValueOf()+.Interface()（且原值不能是 unexported 字段） - 对 nil 指针调用
reflect.TypeOf(nil)返回nil，不是 *T 的 Type —— 这是高频 panic 点
获取结构体字段名、类型、tag 的正确姿势
只有导出（大写开头）字段才能被 reflect 访问；非导出字段在 reflect.StructField 中不可见，也不会出现在 .NumField() 计数里。
type User struct {
Name string `json:"name" validate:"required"`
email string // 小写 → reflect 不可见
}
u := User{Name: "Alice"}
t := reflect.TypeOf(u)
for i := 0; i < t.NumField(); i++ {
f := t.Field(i)
fmt.Printf("Name: %s, Type: %s, Tag: %s\n",
f.Name, f.Type.String(), f.Tag.Get("json"))
}
// 输出：Name: Name, Type: string, Tag: name
reflect.Value 调用方法前必须检查可调用性
反射调用方法（.MethodByName().Call()）要求：方法必须是导出的、接收者必须是可寻址的（即不能是对字面量或不可寻址临时值的反射）。
-
reflect.ValueOf(u).MethodByName("String")→ panic：u 是值拷贝，不可寻址 - 应改用
reflect.ValueOf(&u).Elem().MethodByName("String") - 调用前务必用
.CanInterface()和.CanCall()判断，否则 runtime panic - 参数必须包装成
[]reflect.Value，每个元素需与方法签名严格匹配（包括指针/值接收者差异）
性能与适用边界：别在热路径用 reflect
reflect 操作比直接类型操作慢 10–100 倍，且无法被编译器内联或优化。它适合配置解析、序列化（如 json）、ORM 映射这类“一次注册、多次使用”的场景，不适合循环体内反复调用。
- 避免在 HTTP handler 中对每个请求做
reflect.TypeOf(req.Body)判定 - 用接口 + 类型断言替代反射判断简单类型：
v, ok := x.(string)比reflect.TypeOf(x).Kind() == reflect.String更快更安全 - 生成代码（如 go:generate + structtag）比运行时反射更可控，比如
easyjson或msgp
真正难的不是怎么调用 reflect，而是判断「这里是否真的需要反射」——多数时候，设计一个清晰的接口契约，比写一堆 reflect.Value.Call() 更可靠。
