安全，Go编译器通过逃逸分析自动将可能被返回的局部变量分配到堆上；用go build -gcflags="-m -l"可查看逃逸结果，“escapes to heap”表示堆分配，“does not escape”则栈分配但取地址时会被强制逃逸。
Go函数返回局部变量指针是否安全？
安全，但前提是该变量在堆上分配——Go编译器会通过逃逸分析自动决定。你写 return &x 没问题，Go不会让你返回栈上已销毁的地址。
怎么判断一个变量会不会逃逸？
用 go build -gcflags="-m -l" 查看逃逸分析结果。关键信号包括：
-
... escapes to heap：变量逃逸到堆，生命周期由GC管理，可安全返回其指针 -
... does not escape：变量留在栈上，若被取地址并返回，编译器会强制让它逃逸（不是禁止，而是重写分配位置） - 闭包捕获变量、传给接口类型参数、作为返回值被外部引用，都大概率触发逃逸
哪些常见写法会意外导致逃逸？
看似简单，实则隐含逃逸风险：
- 返回结构体字段的指针：
return &s.field—— 整个结构体s会逃逸，哪怕只用了一个字段 - 把局部变量传给
fmt.Sprintf或其他接受interface{}的函数：fmt.Sprintf("%v", x)中的x往往逃逸 - 切片字面量直接取地址：
&[]int{1,2,3}[0]—— 整个底层数组逃逸，且容易引发越界或悬垂指针 - 在 for 循环里反复取同一个局部变量地址：
for i := range xs { ps = append(ps, &x) }—— 所有指针最终指向同一个内存位置
逃逸对性能和GC有什么实际影响？
逃逸本身不等于“慢”，但堆分配 + GC 带来间接成本：
立即学习“go语言免费学习笔记（深入）”；
- 每次逃逸都是一次堆分配，高频场景下可能成为
runtime.mallocgc热点 - 小对象逃逸后难以被及时回收，可能延长 GC 周期或增加标记开销
- 结构体字段指针逃逸时，整个结构体无法被栈上内联，失去 CPU 缓存局部性优势
- 调试时看到大量
escapes to heap提示，优先检查是否真需要返回指针——有时返回值拷贝更高效（尤其struct{int64}这类小结构）
逃逸分析是静态的，但它的结论依赖上下文；同一行代码，在不同函数签名或调用链中可能逃逸或不逃逸。别只看单个函数，要结合调用方一起看。
