go编译器自动决定变量栈或堆分配，需理解逃逸原因；用-go:gcflags="-m"查看逃逸，函数返回局部变量地址、赋值给interface{}、goroutine引用、闭包捕获、调用...interface{}函数等必然逃逸；小结构体传值更优因避免逃逸且拷贝成本低，大结构体传指针更合理；逃逸非bug但高频逃逸是性能瓶颈，需结合pprof验证真实调用链。
Go 编译器自动决定变量分配在栈还是堆，你不需要手动指定，但必须理解它“为什么这么判”——否则优化无从下手，性能问题也难以定位。
怎么看变量是否逃逸
最直接的方式是加 -gcflags="-m" 编译：
go build -gcflags="-m" main.go
输出中出现 &x escapes to heap 就说明变量 x 逃逸了。加一个 -m 显示一级分析，加两个 -m -m 会显示更详细的推理路径（比如哪一行的返回、赋值或闭包触发了逃逸）。
- 只看单个函数时，逃逸信息可能不完整；逃逸分析是跨函数、跨包的全局静态分析
- 如果函数被内联（inlined），逃逸行为可能变化；可用
//go:noinline强制不内联来稳定观察 - 输出里出现
movq $0, %rax这类汇编指令，通常意味着栈分配；而调用runtime.newobject则明确指向堆分配
哪些写法必然触发逃逸
不是所有指针都逃逸，但以下场景几乎 100% 触发：
- 函数返回局部变量的地址：
return &x——x必须活过函数结束 - 把局部变量赋给
interface{}，且值大小超过接口底层可 inline 存储的阈值（目前是 16 字节） - 在 goroutine 中直接引用局部变量：
go func() { println(x) }()—— 编译器无法保证 goroutine 执行完前函数已返回 - 闭包捕获外部变量：
func() int { return n + 1 }中的n若来自外层函数，就逃逸 - 调用接受
...interface{}的函数（如fmt.Sprintf、log.Printf），参数会被装箱到堆
为什么小结构体传值反而比传指针更优
这不是直觉问题，而是逃逸与拷贝成本的权衡：
- 一个
struct{ a int; b int }（16 字节）传值，拷贝开销极小，且不会逃逸；传指针则大概率让该结构体逃逸到堆 - 但如果结构体含 slice、map、channel 或大数组（比如
[1024]byte），传值拷贝代价高，此时传指针更合理，且逃逸已不可避免 - 方法接收器类型也影响逃逸：值接收器方法若被指针调用（
(&s).Foo()），仍可能导致s逃逸；而指针接收器方法对值调用（s.Foo()）会隐式取地址，同样触发逃逸
逃逸不是 bug，但高频逃逸就是性能瓶颈
逃逸本身合法且必要，问题在于频率和规模：
- 一次
newInt()返回指针，逃逸一次，无关痛痒；但在每毫秒执行千次的 HTTP handler 里反复fmt.Sprintf，就会持续申请堆内存，拖慢 GC 周期 - 用
pprof查runtime.MemStats.HeapAlloc和GC pause时间，比单纯看逃逸提示更有说服力 - 优化优先级：先确认是否真有性能问题 → 定位热点函数 → 查逃逸 → 改写（如换
strings.Builder替代fmt.Sprintf）→ 再测
真正容易被忽略的是：逃逸分析结果依赖于上下文。同一段代码，在测试文件里不逃逸，放进 HTTP handler 后因被闭包捕获或传入 interface 就逃逸了——所以必须在真实调用链里验证。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
