因为编译器无法静态证明指针不会外泄，只要&x可能被外部持有（如返回、存全局变量、传goroutine等），就必须分配到堆上以避免访问已销毁栈内存。
为什么 &x 一出现，变量就大概率上堆？
Go 编译器看到 &x，不会立刻判定逃逸，而是看这个指针“会不会活过函数返回”。只要存在任何可能被外部继续使用的路径，它就会把 x 分配到堆上。这不是保守，是必须——栈帧返回后，原地址就失效了。
常见触发点包括：
- return &x（几乎 100% 逃逸）
- someGlobalMap["key"] = &x（全局容器持有指针）
- go func() { use(&x) }()（goroutine 可能长期运行）
- interface{}(x) 或 fmt.Println(x) 中 x 是大结构体且未实现 String()（底层转成 interface{} 持有副本或指针）
哪些看似安全的写法其实偷偷逃逸？
很多开发者以为“只在函数内用指针”，就没事——但编译器不这么认为。关键不是你 *怎么用*，而是它 *能不能静态证明指针不会外泄*。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
容易踩坑的场景：
- log.Printf("%v", bigStruct{})：没实现 String()，fmt 内部反射装箱，整个结构体逃逸
- for i := range data { p := &Item{i}; sendToChan(p) }：每次循环都 new 一个堆对象，高频分配直接拉高 GC 频率
- func New() *T { return &T{...} }：构造函数返回指针，T 逃逸；若 T 很小（如 struct{a,b int}），值返回更高效
- slice := make([]byte, 0, 1024); sub := slice[100:200]; globalBuf = sub：底层数组被全局变量钉住，1024 字节全无法回收
go build -gcflags="-m -l" 看到什么才算真逃逸？
输出里出现这些关键词，基本可确认逃逸：
- ... moves to heap
- ... escapes to heap
- leaking param: x（参数 x 泄露到函数外）
- stored into ...（存入 map/slice/全局变量等）
注意：
- 一定要加 -l（禁用内联），否则逃逸信息会混在调用方里，误判率极高
- 如果看到 escapes to heap 但紧接着是 but is not dereferenced，说明编译器识别出这是“假逃逸”（比如仅用于计算偏移），实际未上堆
- fmt.Println(&x) 在 Go 1.19+ 通常不逃逸，因为 fmt 不保留该指针；但 fmt.Sprintf("%p", &x) 就可能逃逸（字符串需持久化）
sync.Pool 能缓解逃逸，但不能掩盖设计问题
sync.Pool 是给 *已经逃逸的对象* 提供复用路径，不是让逃逸变得合理。它解决的是“高频分配→高频 GC”的症状，而非“为什么非得逃逸”的病因。
使用时的真实限制：
- 放进 Pool 的对象可能被随时清理，不能依赖其生命周期
- 若结构体含指针字段（如 *bytes.Buffer），Pool 复用时若未重置，旧指针残留会延长其他对象生命周期
- 小结构体（≤48 字节）建议存值而非指针，避免额外一层堆分配
- 更有效的做法是：先用 -gcflags="-m -l" 定位逃逸源头，改用值传递、拆分结构体、显式拷贝或预分配，把逃逸从根上掐掉
最常被忽略的一点：逃逸本身不可怕，可怕的是“逃逸 + 长期持有”。一个 &User 存进全局 map 十分钟不删，和它是否在栈上分配已无关系——它已经被 GC 标记为永远可达。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
