interface{}赋值多数导致堆分配，因编译器需保守假设值可能被长期持有；小整数或≤16字节无指针结构体可能不逃逸，而字符串、切片等几乎必然逃逸。
interface{} 赋值操作本身就会触发逃逸分析介入，绝大多数情况都会导致堆分配——这不是 bug，而是编译器对动态类型的保守决策。
为什么 interface{} 赋值会逃逸
Go 编译器看到 var i interface{} = x 这类语句时，无法在编译期确定 x 后续是否会被保存、复制、跨 goroutine 使用或参与反射。为保证运行时安全，它必须假设最坏情况：该值可能被长期持有。
- 小整数（如
42、int64(1)）或 ≤16 字节且无指针字段的结构体，interface{}可能直接把值塞进接口的data字段，不逃逸 - 字符串、切片、map、大结构体（>16 字节）、含指针字段的结构体、闭包捕获变量——几乎必然逃逸，因为它们底层依赖堆内存或需额外指针间接访问
- 关键证据来自
go build -gcflags="-m -l"：输出中出现&x escapes to heap或leaking param: x就是明确信号
fmt.Println 是最隐蔽的逃逸触发器
fmt.Println 签名是 func Println(a ...interface{})，所有非接口参数都会被隐式装箱成 interface{}。高频调用时，这会持续产生堆分配。
-
fmt.Println("hello")→ 字符串头结构体（含指针）逃逸 -
fmt.Println([]byte{1,2,3})→ slice header + 底层数组全逃逸 -
type Big struct{ data [1024]byte }; fmt.Println(Big{})→ 超 16 字节，强制堆分配 - 即使你传的是局部变量地址：
fmt.Println(&local)，只要local是栈变量，编译器也会把它挪到堆上再取址
用 unsafe 和 eface 结构体验证内存布局
空接口 interface{} 在运行时对应 eface 结构体：struct { _type *_type; data unsafe.Pointer }。你可以用 unsafe.Pointer 强转观察其内容，确认逃逸是否发生。
type eface struct {
_type *_type
data unsafe.Pointer
}
func main() {
var i interface{} = "hello" // 触发逃逸
ti := i
fmt.Println("type:", *(*eface)(unsafe.Pointer(&ti))._type)
fmt.Println("data:", *(*string)((*eface)(unsafe.Pointer(&ti)).data))
}
若输出中 data 指向的地址与栈帧无关（比如高位地址、非 SP 附近），基本可断定已分配在堆上。配合 -gcflags="-m -l" 输出交叉验证更可靠。
指针接收器方法会让值传递也变相逃逸
定义 func (t *T) M() 时，哪怕你传的是 T{} 值，只要它要满足该接口的方法集，编译器就必须取地址——这就等于写了 &t，强制逃逸。
- 值接收器
func (t T) M()允许直接拷贝，更容易留在栈上 - 所以别只看“我传的是值”，要看“这个值能不能满足目标接口的方法集”
- 常见坑：
var w io.Writer = bytes.Buffer{}→Write是指针接收器，bytes.Buffer{}会被取址并逃逸
真正难察觉的不是“什么时候逃逸”，而是“为什么这个明明很小的变量也逃逸了”——往往是因为它被赋给了 interface{}，而那个接口又被返回、存入 map、或进了 goroutine。盯住每一处 interface{} 出现的位置，比优化算法更能立竿见影地压低 GC 压力。
