直接回答：编译期静态分析变量的生命周期是否“逃出”函数作用域：不逃逸则栈分配（函数返回即释放，零 GC 成本），逃逸则堆分配。典型逃逸：返回局部变量指针、interface 装箱（动态类型需堆存）、闭包捕获后被外部持有、channel 发送指针、切片扩容超编译期可知大小。

展开解析：读报告：go build -gcflags="-m -m" 输出逃逸决策与原因（-m=2 给出数据流），重点看 moved to heap 与 escapes to heap。高频场景与对策：结构体指针返回——若仅内部使用考虑返回值类型（大结构体另算，拷贝成本权衡）；interface 逃逸——fmt 族函数参数全走 interface{}，热路径换 strconv.AppendXxx 或 zerolog 这类零分配 API；闭包逃逸——回调注册类把闭包存起来必然逃逸，改用显式 struct 加方法；make([]T, n) n 不定——超过栈分配阈值（10MB 栈上限，编译期 64KB 元素级判定）上堆，容量已知时尽量常量或 sync.Pool 复用。优化纪律：先 pprof alloc_space 找到分配热点再查逃逸——逃逸分析优化只对热路径有价值，冷路径强行去逃逸反而把代码写丑；栈变大也有成本（栈拷贝扩容、goroutine 栈占用），把大数组从堆挪栈未必划算。验证手段：benchmark 加 -benchmem 看 allocs/op 与 B/op 变化，目标常是“每操作零分配”。误区：逃逸不等于坏——该上堆的上堆，过度优化栈是另一种病。

追问方向：interface 装箱为何必须堆分配？sync.Pool 复用如何避免逃逸分析失效？

（约 480 字）