go build -gcflags="-m -m" 是查看逃逸分析的最低有效命令；单 -m 仅显示内联决策，双 -m 才输出变量逃逸信息，如 escapes to heap 表示堆分配，does not escape 表示栈上安全。
怎么用 go build -gcflags="-m" 看逃逸分析
直接加 -m 不会输出有用信息，必须至少两次 -m（即 -m -m），否则编译器只报“函数内联决策”，不提变量逃逸。
实操建议：
-
go build -gcflags="-m -m" main.go是最低有效命令；加三次-m（-m -m -m）会显示更细的优化步骤，但通常没必要 - 如果代码有多个文件，建议指定具体文件，避免被其他包日志淹没：
go build -gcflags="-m -m" ./cmd/myapp - 想聚焦某个函数？用
-m=2+ 函数名过滤：go build -gcflags="-m=2 -m" main.go 2>&1 | grep "MyFunc" - 注意：Windows cmd 中
2>&1无效，得用 PowerShell 或重定向到文件再findstr
can't escape 和 escapes to heap 到底啥意思
这是逃逸分析最常撞见的两个结论，但含义相反，容易看反。
关键看主语是谁——是“变量”还是“指针”：
立即学习“go语言免费学习笔记（深入）”；
-
var x int escapes to heap：这个x会被分配到堆上（比如它地址被返回、传给 goroutine、或放进切片/映射），生命周期超出当前栈帧 -
&x does not escape：取地址操作本身没逃逸，说明编译器确认x的地址不会泄露出去，x还能留在栈上 - 常见误读：
does not escape不代表“绝对安全”，只是当前上下文没逃逸；加个 channel send 就可能变escapes to heap
为什么加了 sync.Pool 反而让变量逃逸了
sync.Pool 的 Put 方法接收 interface{}，任何传进去的值都会被装箱，强制逃逸到堆——这是语言机制决定的，不是 bug。
实操判断点：
- 只要出现
Put调用，对应变量几乎必逃逸；Get返回的值也大概率已堆分配 - 想验证？对比加
Put前后-m -m输出，关注那行... escapes to heap是否新增 - 性能敏感路径慎用
sync.Pool存小对象（如struct{a,b int}），逃逸开销可能大于内存复用收益
逃逸分析在 CGO 或 interface{} 场景下基本失效
一旦涉及 C.CString、C.GoBytes 或任意 interface{} 接收，编译器就放弃精确追踪，直接标记为逃逸。
这不是配置问题，是设计限制：
-
fmt.Sprintf里传结构体？逃逸。因为底层走interface{}+ 反射 -
json.Marshal输入非指针？逃逸。即使结构体很小，序列化过程无法静态确定生命周期 - CGO 函数参数含 Go 指针？编译器无法验证 C 侧是否长期持有，一律堆分配保安全
这类场景别纠结逃逸结果，重点看实际压测中的 GC 频率和堆增长趋势——分析器输出此时只是参考。
