interface{}转换在热路径中会拖慢性能，因其非零成本：每次赋值或类型断言需运行时检查类型并复制数据，尤其大结构体开销显著，高频场景下加剧GC压力与CPU消耗。
为什么 interface{} 转换在热路径里会拖慢性能
Go 的 interface{} 不是零成本抽象。每次赋值或类型断言，运行时都要做两件事：检查底层类型是否匹配、拷贝数据（尤其对大结构体）。如果在循环、HTTP handler 或高频计算中反复做 val.(MyType) 或 reflect.TypeOf(val)，GC 压力和 CPU 开销会明显上升。
- 小对象（如
int、string）转换开销小，但累积起来仍可观 - 大结构体（比如含切片或 map 的 struct）被装箱进
interface{}时，底层数据会被复制一次 -
type switch比单次断言稍快，但仍是线性查找，分支多时不如直接用泛型
泛型替代 interface{} 的三个典型场景
不是所有地方都该上泛型，但以下模式替换后收益最直接：
- 工具函数封装：比如
func Max(a, b interface{}) interface{}→ 改成func Max[T constraints.Ordered](a, b T) T - 容器包装：
type Stack struct { data []interface{} }→ 改成type Stack[T any] struct { data []T }，避免出栈时每次都要断言 - 回调参数抽象：如
func Do(f func(interface{}))→ 改成func Do[T any](f func(T))，调用方类型信息全程保留，不丢失
泛型不是万能解药：这些坑别踩
泛型带来编译期类型安全，但也引入新约束和隐性成本：
- 每个具体类型实例（如
Stack[int]、Stack[string]）都会生成独立函数/方法代码，二进制体积增大 —— 对嵌入式或 CLI 工具要留意 - 不能对泛型参数做反射操作：
reflect.TypeOf(T)不合法，T是类型形参，不是运行时值 - 约束（constraint）写错会导致晦涩错误，比如用
comparable约束却传入含 slice 字段的 struct，编译失败但提示不直观 - 与老代码交互时，仍需在边界处做一次
interface{}转换（比如调用只接受interface{}的第三方库），这部分无法消除，只能尽量收口
什么时候还该用 interface{}
泛型解决不了所有抽象需求，以下情况保持 interface{} 更自然：
立即学习“go语言免费学习笔记（深入）”；
- 真正需要运行时多态：比如插件系统、策略注册表，类型在加载时才确定
- JSON/YAML 解析中间层：
json.Unmarshal([]byte, &v)中v是interface{}，因为结构未知 - 日志字段、监控标签等“任意键值对”场景，类型不确定且不参与计算，强行泛型反而增加维护负担
泛型的价值不在“取代 interface”，而在于把那些本就该在编译期定死的类型关系显式表达出来。漏掉这一点，很容易写出又泛又慢的代码。
