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