reflect.AssignableTo判断赋值兼容性而非类型相等，如*int可赋给interface{}但二者类型不同；判同一类型应直接用==比较reflect.Type。
reflect.AssignableTo 判断的是赋值兼容性，不是类型相等
很多人一看到 reflect.AssignableTo 就以为它能判断“两个类型是不是一样”，其实完全不是。它只回答一个问题：“能不能把左边类型的值，赋给右边类型的变量？”——这和类型相等（reflect.Type == reflect.Type）是两回事。
比如 *int 可以赋给 interface{}，所以 (*int).AssignableTo(interface{}的Type) 返回 true，但它们显然不是同一个类型。
真正要判断“是否为同一类型”，直接用 == 比较两个 reflect.Type 值即可，这是最准、最快、最无歧义的方式。
什么时候该用 AssignableTo 而不是 ==
典型场景是泛型约束不满足、接口实现检查、或运行时动态赋值前的安全校验。比如写一个通用的结构体字段填充函数，需要确认传入值的类型能否塞进目标字段。
立即学习“go语言免费学习笔记（深入）”；
- 目标字段是
io.Writer，你手头有个*os.File：用fileType.AssignableTo(writerType)判断是否合法 - 想确认某个类型是否实现了某个接口（如
error）：t.AssignableTo(reflect.TypeOf((*error)(nil)).Elem().Type) - 做反射版的类型断言：不是看“是不是 error”，而是“能不能当 error 用”
注意：接口类型之间不能用 == 判断是否“可互换”，必须用 AssignableTo 或 Implements。
AssignableTo 的常见误判和坑
这个方法表面简单，实际容易掉进几个隐含陷阱：
-
AssignableTo不考虑指针间接层数：比如int不能赋给*int，但*int可以赋给**int—— 这种链式关系它不自动推导 - 底层类型相同但命名类型不同（如
type MyInt int和int）：默认不可赋值，除非有显式转换；AssignableTo严格遵循 Go 规范，不会绕过命名类型检查 - 对未导出字段或非导出类型调用时，如果来源类型来自其他包且字段不可见，
AssignableTo可能返回false即使语法上允许（比如包内私有类型别名） - 数组长度参与比较：
[2]int和[3]int类型完全不同，AssignableTo必然返回false，哪怕元素类型一致
替代方案：Implements 和 ConvertibleTo 的分工
如果你的目标是“是否实现了某接口”，优先用 Implements，它语义更清晰、行为更稳定：
if t.Implements(reflect.TypeOf((*io.Writer)(nil)).Elem().Type) {
// t 是某个实现了 io.Writer 的类型
}
而 ConvertibleTo 更接近强制类型转换（类似 T(v)），比 AssignableTo 条件更宽松（例如 int 可转为 int64，但不能直接赋值）。三者用途分明：
-
==：类型完全一致（同一 Type 对象） -
AssignableTo：能否出现在赋值语句右边（x = y是否合法） -
ConvertibleTo：能否显式转换（T(y)是否合法） -
Implements：是否满足接口契约（专用于接口类型）
实际写业务逻辑时，多数时候你要的不是“能不能赋值”，而是“是不是这个类型”或者“有没有实现这个接口”——这时候硬套 AssignableTo 反而让逻辑变模糊。
