变量逃逸这事儿，说穿了，根本不是代码写错了，而是编译器在跟你喊话：“这家伙活不过当前函数，你确定要把它塞到堆上吗？”——你得学会听懂这句潜台词。
怎么一眼看出哪个变量逃逸了
想一眼看穿逃逸，用 go build -gcflags="-m -l" 编译，重点关注三类输出：&x escapes to heap（取地址逃逸）、leaking param: x（参数被外部拿走了）、moved to heap（结构体或切片底层数组被推上堆）。加 -l 是为了关掉内联，否则逃逸信息会混在调用方里，根本没法定位。别信直觉，举个例子，一个 16 字节的 struct，只要函数返回了 &v，它就一定逃逸；而一个 100 字节的 struct，如果全程没取地址、没传接口、没进 goroutine，大概率稳坐栈上。
哪些写法会悄悄把变量送上去
这些看似无害的写法，却是不折不扣的逃逸大户：
fmt.Println(v)或fmt.Sprintf("%v", v)：只要v是非接口类型（比如 struct），就会装箱成interface{}，触发拷贝并逃逸。- 闭包捕获局部变量：哪怕只是读一下，整个变量也会上堆。如果这个闭包又被传给
go f()，那基本就锁死堆分配了。 - 函数返回
make([]T, 0, N)后的 slice：header 本身不逃逸，但底层数组一旦被 append 触发扩容，并且 slice 被返回，数组就跟着逃逸了。 - 方法接收者是指针，方法内又对局部变量取地址并返回：那个局部变量必然逃逸，跟接收者是谁没关系。
map[string]interface{}在循环中构造：每次 new 都逃逸，而且 key/value 的 interface{} 包装开销还会层层叠加。
怎么让变量老老实实待在栈上
核心思路其实就三个词：缩短生命周期、切断外部引用、避免隐式转换。具体来说：
- 小结构体（≤48 字节）优先用值传递，别一上来就加
*。比如type Point struct{ X, Y int }，直接传Point比传*Point更不容易逃逸。 - 用
strings.Builder替代fmt.Sprintf或+拼接字符串，前者能复用底层数组，后者几乎必逃逸。 - 预分配切片容量时用
make([]T, 0, N)，而不是make([]T, N)。后者会立即初始化 N 个零值，不仅多占内存，还容易因为初始 cap 过大导致后续判断失准。 - 把大 struct 拆成多个小字段传参，或者只对真正需要共享的部分用指针。嵌套 struct 中某个字段逃逸，常常会拖累整个结构体。
- 避免把局部变量赋给全局 map/slice/接口变量。哪怕只是
globalCache[key] = v，v就已经逃逸了。
sync.Pool 不是万能解药，用错反而更糟
Pool 的本质是“延迟释放”，不是“避免分配”。它适合生命周期短、构造贵、类型固定的对象（比如 bytes.Buffer、自定义 parser 结构体），但有硬性限制：
- 池中对象不能包含
io.Reader、net.Conn或未清空的map/slice，否则可能污染后续使用，甚至引发 goroutine 泄漏。 - 基准测试里
sync.Pool容易产生假阳性。go test -bench默认复用上下文，Pool 对象跨轮次存活，0 allocs/op不代表线上就不逃逸。正确的做法是：把pool := &sync.Pool{...}放进b.Run内部，或者配合-gcflags="-m"看真实逃逸情况。 - Pool 无法解决根本逃逸。如果对象本身因为返回指针或闭包捕获而必须上堆，Pool 只是把它从 GC 管理换成了手动复用，并没有减少首次分配的压力。
需要特别提醒的是：逃逸分析结果高度依赖函数边界和内联行为。同一个函数，单独编译时逃逸，被内联后可能完全不逃逸。所以，优化前先跑 -gcflags="-m -l" 看裸逃逸，优化后别忘了去掉 -l 再验证一次——毕竟生产构建默认是开启内联的。
