interface{}赋值必然触发堆逃逸，因eface需存类型元数据和值/地址，编译期无法确定大小与生命周期；小结构体被完整拷贝，大结构体存指针；any等价interface{}；指针接收者方法要求显式传指针；泛型可规避逃逸。
interface{} 赋值必然触发堆逃逸，不是“可能”，是“一定”
只要把任意非基本类型（struct、slice、map、func 等）赋给 interface{}，Go 编译器就会把它分配到堆上。这不是 bug，是设计使然——eface 需要存储类型元数据指针和值/地址，而编译期无法确定大小与生命周期，只能保守逃逸。
- 验证方式：加
go build -gcflags="-m -l"，看到escapes to heap且紧邻fmt.Println、json.Marshal或自定义接收interface{}的函数调用行 - 小结构体（如
struct{a,b int}）逃逸后被完整拷贝进堆；大结构体则只存指针，但多一次间接寻址 -
any和interface{}完全等价，换名不换行为，别指望靠改关键字绕过逃逸
指针接收者方法导致接口不满足，编译错误不是运行时问题
定义了 func (t *T) M()，却用 T{} 值去赋接口变量，Go 直接报错：cannot use T literal (type T) as type X in assignment: T does not implement X (M method has pointer receiver)。这不是类型断言失败，是编译期就拒绝的硬性约束。
- 值接收者方法：
func (t T) M()→T和*T都能满足同一接口 - 指针接收者方法：
func (t *T) M()→ 只有*T满足，T{}即使字段全零也不行 - 常见陷阱：在 map 或 slice 中存
T{}，再试图遍历转成接口；正确做法是存&T{}或统一用指针初始化
动态注册方法 ≠ 动态实现接口，二者不能混为一谈
用 map[string]func() 存方法、再通过反射调用，这只是在运行时做方法分发，**并未让某个类型自动满足某接口**。接口仍需由具体类型显式实现（哪怕只是转发），否则 var x io.Writer = myObj 会编译失败。
- 真正可行的动态适配方式：定义一个通用包装类型（如
DynamicHandler），在其指针接收者方法里调用闭包或 map 查找，从而满足接口（如http.Handler） - 反射调用
reflect.Value.Call是纯运行时行为，不参与接口满足性检查，也不能替代方法集声明 - 若真需“运行时决定实现哪套方法”，应提前设计好接口契约，用组合+字段切换（如状态机）代替反射
泛型替代 interface{} 是最直接的逃逸规避手段
当函数逻辑不依赖接口抽象，只是想写个通用工具（比如打印、序列化、校验），用泛型比空接口更高效、更安全。
- 示例：
func Print[T fmt.Stringer](v T) { fmt.Println(v.String()) }—— 编译期实例化，无interface{}装箱，不逃逸，还能内联 - 泛型二进制体积会略增，但对高频调用路径（如日志、中间件）收益远大于成本
- 若只有一两处调用，直接传具体类型（如
func ProcessUser(u *User)）比泛型更轻量，也彻底规避逃逸
io.Writer 这类非空接口看性能，却没意识到 fmt.Printf("%v", hugeStruct) 这一行才是真正的 GC 热点。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
