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 再比 AssignableTo，容易忽略地址性与零值影响。例如：
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 判断原始类型兼容性。
立即学习“go语言免费学习笔记（深入）”；
- 传入
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 发现，得靠构建期类型对齐或接口抽象来规避。
