空接口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。

Alibabacloud Sdk Client Initialization For Golang

初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。

下载

• 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 开销。

• 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 突增。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！