加 -gcflags="-m -l" 可准确判断变量逃逸：若输出 xxx escapes to heap 则逃逸；禁用内联（-l）确保定位到定义行；常见逃逸场景包括闭包捕获、切片扩容、传指针给全局容器等。
怎么一眼看出变量逃逸没逃逸
直接跑 go build -gcflags="-m -l"，别省掉 -l。它禁用内联，让逃逸信息落在真正定义变量的那行，而不是混在调用方里。如果看到类似 xxx escapes to heap 或 moved to heap 的提示，说明变量被编译器判为逃逸。
常见干扰项：函数被内联后逃逸消失，但你没加 -l 就看不到原始判断；或者 fmt.Println(v) 里 v 是个没实现 String() 的大结构体，会被反射装箱成 interface{}，触发逃逸——这不是 bug，是接口泛型调用的代价。
高频函数里哪些写法会把小结构体“拱”上堆
不是所有“返回指针”都合理。比如一个 func NewRequest() *Request，若 Request 只有 3 个 int 字段（共 24 字节），值传递开销远小于堆分配+GC压力。改成 func NewRequest() Request 后，逃逸分析通常显示 does not escape。
- 闭包捕获局部变量后又被 goroutine 使用（如
go fn()），变量必然逃逸 - 切片初始容量不足，
append触发扩容，底层数组可能上堆（尤其长度 > 64 字节时） - 把局部变量地址传给
chan *T、全局 map、或任何可能跨 goroutine 存活的容器
sync.Pool 不是万能解药，用错反而更慢
sync.Pool 适合固定大小、构造开销大、生命周期短且与 goroutine 绑定的对象，比如 bytes.Buffer、json.Decoder。但它不解决逃逸本身，只是缓解堆分配频率。
立即学习“go语言免费学习笔记（深入）”；
容易踩的坑：
- 往 Pool 里放含指针的大型结构体，GC 扫描成本飙升，还可能延长其他对象存活时间
- 误以为 Pool 能自动限流——
New只在Get空时调用，但Put不限制数量，突发流量下对象堆积在堆上不释放 - 在非热点路径滥用 Pool，同步开销盖过复用收益
验证是否真有效：压测前后跑 runtime.ReadMemStats，重点看 HeapAlloc 和 NumGC 变化，别只盯 Alloc。
值传递和指针传递到底怎么选
没有银弹规则，得看字段数和大小。经验阈值是：总尺寸 ≤ 指针宽度（通常 8 字节）时，值传递更优；超过 3–4 个字段或含 slice/map/ptr 字段时，指针更安全。
特别注意：切片和 map 本身是指针包装，传参时不拷贝底层数组，所以 func f(s []int) 不会因切片内容大而逃逸，但 func f(*[]int) 会——因为指针暴露了作用域。
真正关键的是变量生命周期是否可控。一个高频函数里反复 new(T) 再取地址，不如预分配一个池或复用栈变量；而一个只读场景下传 *T 却又不修改，纯属诱导逃逸。
逃逸分析结果高度依赖上下文，同一行代码在内联后可能完全不逃逸。别迷信单个函数的 -m 输出，要结合调用链整体看。
