new(T) 与 &T{} 逃逸分析一致性解析

在 Go 中，`new(T)` 和 `&T{}` 虽然都生成指向零值的指针且语义等价，但逃逸行为截然不同：`new(T)` 总是强制逃逸到堆，而 `&T{}` 是否逃逸则完全取决于指针的实际使用方式——若未被返回、未存入全局容器或未传入逃逸闭包，它就可能安静地留在栈上，避免 GC 开销；这种差异源于编译器将 `new` 视为明确的“堆分配指令”，而 `&T{}` 则可参与完整的逃逸分析。频繁滥用 `new(T)`（尤其在循环中）会显著增加堆分配和 GC 压力，而合理使用 `&T{}` 或局部变量过渡能有效提升性能，因此日常开发中应优先选择后者，仅在极少数无法用变量承接的场景（如初始化 map 的 *int value）才考虑 `new`。

二者在逃逸行为上不一致 —— 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。

今天关于《new(T) 与 &T{} 逃逸分析一致性解析》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！