AssignableTo 判断类型赋值兼容性而非结构等价，仅检查顶层类型关系，如接口实现、指针转换等；对命名类型与底层类型、interface{}包装值、nil等场景易误判，应优先使用泛型或接口替代反射判断。

AssignableTo 是类型赋值兼容性的判断依据，不是结构等价性检查

Go 的 AssignableTo 方法只回答一个问题：「能否把一个类型的值直接赋给另一个类型的变量」，不关心字段名、标签、方法集是否一致。比如 *int 可以赋给 interface{}，但 int 不能赋给 *int —— 这正是 AssignableTo 要捕获的语义。

常见误用是拿它当「两个 struct 是否一样」的判断工具，结果发现明明字段完全相同却返回 false。这是因为 Go 中只有「同一类型」或满足「可赋值规则」（如接口实现、指针/非指针转换）才算通过，而非结构等价。

• AssignableTo 不递归比较嵌套结构，只看顶层类型关系
• 接口类型之间判断依赖方法集子集关系，不是名称匹配
• 底层类型不同（如 type MyInt int 和 int）默认不可相互赋值，除非显式转换

reflect.TypeOf(x).AssignableTo(reflect.TypeOf(y)) 的典型误判场景

直接对两个值调用 reflect.TypeOf 再比 Assignabl

var a int = 42
var b *int
fmt.Println(reflect.TypeOf(a).AssignableTo(reflect.TypeOf(b))) // false —— int 不能赋给 *int
fmt.Println(reflect.TypeOf(&a).AssignableTo(reflect.TypeOf(b))) // true —— *int 可赋给 *int

更隐蔽的问题是 interface{} 值：它包装后类型变成 interface{}，而原类型信息丢失。所以别对 interface{} 参数直接用 AssignableTo 判断原始类型兼容性。

• 传入 nil 会导致 reflect.TypeOf(nil) 返回 nil，panic 在 AssignableTo 调用时
• 切片、map、channel 类型的元素类型不参与 AssignableTo 比较，仅比较容器本身类型
• 函数类型必须参数个数、类型、返回值完全一致才返回 true

替代方案：用 reflect.Type.ConvertibleTo 处理类型转换场景

当你要判断是否能用 value.Interface().(T) 或 T(value.Interface()) 强转时，ConvertibleTo 比 AssignableTo 更贴近实际需求。它覆盖更多合法转换，包括：

• 底层类型相同的命名类型互转（type A int ↔ type B int）
• 整数类型间宽窄转换（int8 → int16），但需在运行时值不越界
• 字符串 ↔ []byte / []rune（仅限字面量或已知安全上下文）

注意：ConvertibleTo 是编译器允许的转换集合，不代表运行时不 panic；它不检查值范围，只看类型定义是否允许该转换路径。

type MyID int
var x MyID = 100
t1 := reflect.TypeOf(x)
t2 := reflect.TypeOf(int(0))
fmt.Println(t1.AssignableTo(t2))     // false —— 命名类型不能直接赋给底层类型
fmt.Println(t1.ConvertibleTo(t2))    // true —— 允许显式转换

真实项目中应优先用类型断言或泛型约束，而非反射判断

反射判断类型兼容性通常意味着设计上已失去类型控制权。比如 handler 函数接收 interface{} 后再用 AssignableTo 分支处理，不如改用泛型：

func Handle[T Person | Product](item T) { ... }

或者用明确定义的接口代替运行时类型检查：

type Storable interface {
    TableName() string
    ToMap() map[string]interface{}
}

只有在必须对接未知第三方数据（如 JSON 解析后动态分发）、或编写通用序列化工具时，才值得投入精力写健壮的 AssignableTo + ConvertibleTo 组合逻辑。此时务必加上 nil 检查、Kind 判断（避免对 reflect.Invalid 调用方法），并为每种失败路径留出明确错误提示。

最常被忽略的一点：反射获取的 reflect.Type 对象不包含包路径的 runtime 重映射信息，跨 module 时同名类型可能被视为不同类型 —— 这类兼容性问题无法靠 AssignableTo 发现，得靠构建期类型对齐或接口抽象来规避。