reflect.TypeOf() 返回 reflect.Type 而非原始类型，因 interface{} 参数擦除类型信息；它仅提供只读结构描述，不能直接赋值或断言；需配合 reflect.ValueOf().Interface() 还原值，且仅导出字段可见。

Go 的 reflect 包不是用来“动态创建类型”或“绕过类型系统”的，它只在运行时读取已知类型的结构信息——如果你期望像 Python 那样自由地 new 任意类型、调用任意方法，会踩坑。

为什么 reflect.TypeOf() 返回的是 reflect.Type 而不是原始类型？

reflect.TypeOf() 接收一个 interface{}，擦除了原始类型；它返回的 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() 更可靠。