赋值给 interface{} 时，小整数或≤16字节无指针结构体通常不逃逸；切片、map、字符串、大结构体、含指针结构体及闭包捕获变量几乎必然逃逸，尤其与指针接收器、反射、goroutine混用时易引发逃逸链。
interface{} 赋值时哪些值会逃逸
只要值被赋给 interface{}，编译器就无法在编译期确定其后续使用方式，绝大多数情况都会触发逃逸。但逃逸与否取决于值的大小和类型：小整数（如 int、int64）或小结构体（≤16 字节且无指针字段）可能不逃逸；而切片、map、字符串底层数据、大结构体、含指针字段的结构体，几乎必然逃逸。
常见错误现象是：函数返回 interface{} 或接收 interface{} 参数后，内部临时变量莫名出现在堆上，GC 压力上升。
-
var i interface{} = 42→ 不逃逸（常量整数直接塞进接口数据域） -
var s = "hello"; i = s→ 逃逸（字符串头结构体含指针，必须堆分配） -
var m = map[string]int{"a": 1}; i = m→ 逃逸（map 是引用类型，底层 hmap 必须堆分配） -
type Big struct{ data [1024]byte }; i = Big{}→ 逃逸（超 16 字节，且无法内联到接口数据域）
为什么接收 interface 参数的函数容易让实参逃逸
当函数签名是 func f(v interface{})，而你传入一个局部变量（比如 data := []byte{1,2,3}），这个 data 很可能逃逸——不是因为函数用了它，而是因为编译器无法证明该值在函数返回后不会被保存、复制或跨 goroutine 使用。
尤其危险的是把局部切片、结构体指针、闭包传给 interface 参数函数。编译器看到“可能被任意 runtime 接口逻辑捕获”，就保守地全扔堆上。
- 避免写
f(interface{}(localSlice))，改用具体类型参数f(slice []byte) - 如果必须用 interface（如日志、泛型兼容层），优先传值而非地址：
f(myStruct{})比f(&myStruct{})更不容易逃逸（后者强制指针逃逸） - 注意
fmt.Printf("%v", x)内部就是interface{}接收，高频调用时x若是大对象，会持续堆分配
interface 实现类型中的指针接收 vs 值接收对逃逸的影响
定义方法时用指针接收器（func (t *T) M()）本身不导致逃逸，但一旦你把 T 值赋给 interface，编译器就必须取地址才能满足方法集，从而引发逃逸。值接收器（func (t T) M()）则允许直接拷贝，更易留在栈上。
典型陷阱：你有一个小结构体 type User struct{ ID int; Name string }，只实现了 func (u *User) String() string。那么 var u User; fmt.Println(u) 中的 u 会被取地址传入 fmt.Stringer 接口，逃逸。
- 若结构体适合栈分配，优先用值接收器实现接口方法
- 不要为省一次拷贝而盲目用指针接收器——它可能换来更重的堆分配和 GC 开销
- 可通过
go build -gcflags="-m" main.go确认：输出中出现... moved to heap: u即表示逃逸发生
闭包 + interface 组合是最隐蔽的逃逸放大器
当你在一个函数里创建闭包，并在闭包中访问局部变量，再把这个闭包赋给 interface{}（比如作为回调注册进某框架），那个局部变量会经历双重逃逸：先因闭包捕获逃逸到堆，再因 interface 存储再次确认堆分配。
这种组合在中间件、事件监听、HTTP handler 封装中极常见，也是压测时 GC 飙升的元凶之一。
- 避免在闭包内引用大对象（如整个
http.Request或未裁剪的 JSON body） - 如果必须传递上下文数据，提取最小必要字段构造新结构体，而不是直接闭包捕获原始变量
- 用
go tool compile -S查看汇编，可发现 interface 存储最终调用runtime.convT2E或runtime.convI2E，这些函数内部必走堆分配路径
真正难处理的从来不是单点逃逸，而是 interface 与闭包、goroutine、反射混用时形成的逃逸链——一个变量逃逸，可能连带它引用的所有子字段、嵌套结构、甚至整个调用栈帧里的相关变量都被拖进堆。别依赖“应该没问题”，每个 interface{} 出现场景，都值得加一行 -gcflags="-m" 看一眼。
