结论：开销几乎全来自结构体值拷贝，接口头16字节固定且可忽略；赋值时将struct完整复制并配上类型指针，非jvm式装箱。
直接说结论：把结构体赋值给 interface{} 的开销，几乎全来自结构体本身的值拷贝；接口头那两个指针（16 字节）开销固定且可忽略。
struct 赋值给 interface{} 时到底发生了什么
不是“装箱”这个说法误导了很多人——Go 里没有 JVM 那种对象头封装。它只是把整个结构体值复制一份，再配上一个类型指针。内存布局就是：type 指针 + data 指针，后者指向刚拷贝的那份数据。
这意味着：
- 如果结构体很小（比如
Person{string, int}），拷贝成本极低，基本看不出差异 - 如果结构体含大数组（如
[4096]byte）、大 slice 或嵌套 map，拷贝就变成主要瓶颈 - 逃逸分析会告诉你这事：用
go run -gcflags="-m"看到escapes to heap，说明栈上放不下，被迫堆分配，GC 压力立刻上升
interface{} 类型断言 v.(T) 几乎没开销
这不是“查找类型”，也不是反射调用。编译器生成的是两条机器指令：检查 data 是否为 nil，再比对 type 指针是否等于目标类型的地址。实测百万次断言 v.(string) 仅耗时约 1.68 ns/op，和调用 len(s) 差不多。
真正拖慢你的从来不是断言本身，而是这些搭配操作：
-
reflect.ValueOf(v).Interface().(T)—— 先装进反射再拆出来，开销翻两个数量级 - 在
map[interface{}]interface{}里反复断言同一 key 对应的 value —— 瓶颈其实是 map 查找 + 接口装箱，不是断言 - 断言失败后没做
ok判断，直接 panic —— 这属于逻辑错误，不是性能问题
高频场景下怎么避免隐形损耗
别一上来就改接口设计，先看火焰图。用 go tool pprof 看 runtime.ifaceE2I 或 runtime.mallocgc 占比高不高。如果是前者，说明接口方法调用太密；如果是后者，大概率是结构体拷贝导致堆分配过多。
具体可做的几件事：
- 大结构体传参时，优先用
*T而不是T—— 拷贝 8 字节指针，比拷贝几 KB 结构体划算得多 - 避免在 tight loop 里反复把值塞进
interface{}，比如fmt.Printf("%v", x)内部会触发装箱，高频日志建议用预格式化字符串 - 如果必须用空接口容器（如
[]interface{}），考虑预分配容量，减少 append 触发的多次扩容+拷贝
最常被忽略的点：结构体大小和逃逸行为不线性相关。一个含 []byte 的小 struct，可能比不含指针的大 struct 更早逃逸。别只看字段数，要看实际内存布局和编译器判断。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
