go编译器通过逃逸分析决定& t{}分配在栈还是堆：若变量不逃逸（未在函数返回后被外部访问），则栈分配；否则堆分配并加入gc跟踪。
Go 编译器怎么决定 &T{} 放栈还是堆
Go 不会因为你写了 &T{} 就一定堆分配，它看的是“逃逸分析”结果——变量是否在函数返回后仍被外部访问。如果没逃逸，&T{} 的底层内存仍在栈上；一旦逃逸，编译器自动改用堆分配，并插入垃圾回收跟踪。
- 逃逸常见触发点：
return &T{}、赋值给全局变量、传入形参为interface{}或any的函数、作为闭包捕获的变量 - 结构体大小不是决定因素：哪怕
T很大（比如 1MB），只要不逃逸，依然栈分配（栈空间足够时） - 逃逸与否和字段类型强相关：含指针、slice、map、channel、func 字段的结构体更容易逃逸，因为这些类型本身常需堆管理
怎么快速验证 &T{} 是否逃逸
用 go build -gcflags="-m -l" 看编译器决策。加 -l 是禁用内联，避免干扰判断；重复出现的 ... escapes to heap 就是关键信号。
-
go build -gcflags="-m -l main.go输出里若看到&T{} escapes to heap，说明这次分配进了堆 - 如果只看到
movq $type.*T, %rax类汇编片段，没提 “escapes”，大概率留在栈上 - 注意层级嵌套：逃逸可能发生在调用链上游，比如你写
f(&T{})，但真正导致逃逸的是f函数体内把参数存进了 map
&T{} 和 new(T) 在逃逸行为上有区别吗
没有本质区别。两者都产生指向新零值 T 的指针，逃逸分析对它们一视同仁——判断依据全是“这个指针后续会不会活过当前函数作用域”，而不是构造语法。
-
&T{}和new(T)编译后生成的逃逸信息完全一致，可互换验证 - 唯一实际差异：前者支持字段初始化（如
&T{x: 1}），后者只能得零值；但这不影响逃逸判定逻辑 - 别迷信
new(T)更“显式堆分配”——它不强制堆，也不阻止逃逸分析优化
想确保栈分配，但又需要指针怎么办
没法“确保”，只能“引导”。Go 不提供手动栈分配 API，所有栈/堆决策由编译器静态完成。你能做的，是消除逃逸诱因，让编译器愿意放栈上。
立即学习“go语言免费学习笔记（深入）”；
- 避免返回局部指针：
return &T{}是最常见破防点，考虑改用值返回（return T{}）或接收方传入指针 - 慎用
interface{}：把&T{}传给接受interface{}的函数，几乎必然触发逃逸 - 小结构体 + 值传递更安全：如果
T不大（比如struct{ x, y int }），直接传值比传&T更可能留在栈上
真正难处理的是那种“看起来该栈上、却因闭包或泛型推导意外逃逸”的情况——这时得靠 -gcflags="-m" 逐层追日志，而不是凭经验猜。
