interface{}不是万能容器，而是类型擦除的起点：它不声明方法，仅提供编译期擦除能力，值被包装为iface/eface结构，所有取值需显式断言或反射。

interface{} 不是万能容器，而是类型擦除的起点

Go 里 interface{} 的本质不是“可以装任何类型”，而是“不声明任何方法约束”的空接口。它不提供行为抽象，只提供编译期类型擦除能力——值被传入时，运行时会打包成 iface 或 eface 结构（含类型元信息和数据指针）。这意味着：它本身不做类型转换，也不自动解包；所有“取值”操作都必须显式断言或反射。

真正该用 interface{} 的三个典型场景

多数人滥用 interface{} 是因为想绕过类型检查，但实际只有少数情况它不可替代：

• 实现泛型前的通用容器（如 map[string]interface{} 解析 JSON 原始字段）
• 函数参数需接收任意类型且不关心具体行为（如 fmt.Printf 的 v ...interface{}）
• 与反射交互（reflect.ValueOf(x) 返回 reflect.Value，但输入必须是 interface{}）

注意：Go 1.18 后，绝大多数泛型场景应优先用类型参数，比如 func Max[T constraints.Ordered](a, b T) T，而非 func Max(a, b interface{}) interface{} —— 后者丢失类型、无法直接比较、易 panic。

type assertion 失败时不 panic 的安全写法

直接写 v := x.(string) 在类型不匹配时会 panic。生产代码必须用双值断言：

立即学习“go语言免费学习笔记（深入）”；

if s, ok := x.(string); ok {
    // 安全使用 s
} else {
    // x 不是 string，处理错误或 fallback
}

常见错误包括：

• 对 nil 接口做断言：var x interface{} = nil，此时 x.(string) 会 panic，但 s, ok := x.(string) 中 ok 为 false，s 是 ""
• 嵌套结构误判：JSON 解析后 map[string]interface{} 中的数字默认是 float64，不是 int，断言前要确认实际类型
• 自定义类型未导出字段：断言到具体 struct 类型时，若字段未导出，反射或序列化可能失败

性能与内存开销比你想象中大

每次把一个值赋给 interface{}，Go 运行时都要分配内存存储类型信息，并拷贝值（小值栈拷贝，大值堆分配）。尤其在循环中频繁装箱：

for _, v := range intSlice {
    items = append(items, interface{}(v)) // 每次都触发 iface 分配
}

这会导致：

• 额外的堆分配（即使 v 是 int，也要包装成 eface）
• GC 压力上升（大量短期 interface{} 对象）
• 缓存局部性变差（数据和类型信息分散存储）

如果只是临时传递，考虑用泛型切片 []T；如果用于序列化，优先用 json.RawMessage 或预定义结构体，避免中间层全转 interface{}。

空接口的真实分量不在灵活性，而在它强制你面对类型系统的设计代价：每一次隐式擦除，都意味着一次运行时检查、一次内存布局妥协、一次静态分析失效。用之前，先问自己——这里真的不能用类型参数、具体接口或结构体吗？