空接口interface{}与非空接口底层结构不同：前者为eface（_type+data），后者为iface（tab+data）；赋值时需检查方法集匹配，指针接收者要求传地址；interface{}判nil需同时检查_type和data，仅data为nil不等于nil；类型断言失败会panic，安全断言仅比较类型hash。
空接口 interface{} 和非空接口（如 io.Reader）在底层是两个完全不同的结构体：eface 和 iface。面试官问区别，本质是在考你有没有看过 runtime 源码里的定义。
为什么 var p io.Reader = &bytes.Buffer{} 能过，而 = bytes.Buffer{} 有时不行？
这和 iface 的 itab 构建时机强相关：接口赋值时，运行时要查「具体类型是否实现了接口的所有方法」，而方法集匹配取决于接收者类型（值 or 指针）。
- 如果方法定义在
*T上，那只有&t能赋给接口；t会失败 - 如果方法定义在
T上，那t和&t都可以（Go 会自动取地址或解引用） - 常见错误现象：
cannot use xxx literal (type Y) as type Z in assignment: Y does not implement Z (Method has pointer receiver)
interface{} 判断 == nil 为什么经常出错？
因为 interface{} 是两字段结构：_type（类型信息） + data（数据指针）。只要其中任一字段非零，整个接口变量就不等于 nil。
-
var v interface{}; v = (*int)(nil)→v == nil是false：因为_type已指向*int，data虽为nil，但整体不为空 -
var data *byte; var in interface{}; in = data→in == nil是false：同理，_type已设为*byte - 真正安全的判空方式是先类型断言再判断底层指针，比如
v, ok := in.(*byte); ok && v == nil
类型断言 v.(T) 和安全断言 v, ok := v.(T) 底层开销差在哪？
失败的类型断言会触发 panic，调用 runtime.panicdottype；而安全断言只是查 eface._type 或 iface.tab 是否匹配目标类型，无 panic 开销。
立即学习“go语言免费学习笔记（深入）”；
-
v.(string)失败 → 直接 throw，栈展开、日志、终止当前 goroutine -
v, ok := v.(string)失败 → 仅比较_type.hash与目标类型 hash，返回ok = false - 容易踩的坑：在循环里频繁做失败的
.(T)，性能暴跌且难以定位
什么时候该用 interface{}，什么时候该定义具体接口？
interface{} 不是万能胶水，滥用会导致类型信息丢失、维护成本飙升，也掩盖了本该在编译期发现的问题。
- 适合
interface{}的场景：通用容器（如map[string]interface{}做 JSON 解析）、反射入口（reflect.ValueOf参数）、日志字段传参 - 应该定义具体接口的场景：函数参数、返回值、模块契约——例如用
io.Reader而不是interface{}接收流数据 - 一个信号：如果某个函数参数用了
interface{}，又紧接着做大量switch v.(type)，大概率该拆成多个带具体接口的函数
真正容易被忽略的是：interface 的 nil 判断、类型断言失败路径的性能代价、以及空接口在泛型普及后依然被误用为“通用占位符”——这些地方不出问题则已，一出就是线上静默逻辑错或 CPU 突增。
