new(t) 总是逃逸到堆，&t{} 是否逃逸取决于指针使用方式；前者被编译器视为强制堆分配语义，后者可经逃逸分析留在栈上。
二者在逃逸行为上不一致 —— new(T) 总是逃逸到堆，&T{} 是否逃逸取决于上下文。
为什么 new(T) 一定逃逸
Go 编译器将 new(T) 视为“明确要求堆分配”的语义：它不绑定任何局部变量生命周期，也不参与栈上变量的逃逸分析推导。无论 T 多小、函数多短，只要用了 new，编译器就直接标记为逃逸。
- 执行
go tool compile -m会稳定输出new(T) escapes to heap - 即使
T是int或空结构体，也逃逸；没有例外 - 这和语言设计有关：
new的唯一职责就是“分配零值内存并返回指针”，不提供栈优化入口
为什么 &T{} 可能不逃逸
&T{} 本质是复合字面量取址，编译器会尝试把它当作一个临时变量（如 t := T{}; &t）来分析其生命周期。
- 若该指针未被返回、未存入全局 map/slice、未传入可能逃逸的闭包，则可能留在栈上
- 例如：
func f() { p := &struct{X int}{}; use(p) }中，p很可能不逃逸 - 但一旦写成
return &T{}或m["key"] = &T{}，立刻逃逸 - 字段初始化不影响逃逸判断，只影响值内容（
&T{X: 42}和&T{}逃逸性相同）
实际性能差异在哪
频繁使用 new(T) 会强制触发堆分配，尤其在循环中：
- 每轮迭代都新增一个堆对象 → GC 压力上升 → STW 时间变长
-
&T{}在非逃逸场景下复用栈空间，无 GC 开销 - 二者生成的指针值语义相同，但内存路径不同：一个是“必然堆”，一个是“按需堆”
- 用
go tool compile -gcflags="-m -m"对比两者的逃逸日志，差异一目了然
真正容易被忽略的是：逃逸不是由语法决定的，而是由指针的**使用方式**决定的；但 new 这个函数名本身，已经向编译器发出了“请堆分配”的强信号，绕不开。所以日常开发中，除非你要初始化基础类型指针且无法用变量过渡（比如 map[string]*int 的 value 初始化），否则别碰 new。
