Go逃逸分析：结构体字段不同赋值方式的堆逃逸差异问题

现象复现 #

测试代码如下：

type X struct {
    p *int
}

func main() {
    var i1 int
    x1 := &X{
        p: &i1,
    }
    _ = x1

    var i2 int
    x2 := &X{}
    x2.p = &i2
}

执行编译命令go build -gcflags="-m -m -m"后可见i2被判定逃逸到堆、i1留在栈上，两个结构体实例&X{...}和&X{}均被判定为不逃逸。

判定逻辑拆解 #

这个差异是编译器逃逸分析的分支处理逻辑导致的，和全局生命周期追踪的粒度直接相关：

• i1 不逃逸的原因
  结构体字面量初始化（即&X{字段: 值}的写法）属于编译器特殊处理的构造场景：分析复合字面量的逃逸行为时，编译器会同步追踪所有字段赋值的来源，和结构体本身的逃逸判定做绑定分析。它能明确识别到x1本身全程没有离开main函数栈帧（仅赋值给_，无跨栈帧传递），因此&i1作为字段值，生命周期和栈上的x1完全绑定，不存在被栈外引用的可能，所以i1直接分配在栈上即可。

• i2 逃逸的原因
  先初始化空结构体、再单独执行x2.p = &i2属于通用指针赋值场景，编译器处理这类独立赋值语句时走的是保守判定规则：只要检测到局部变量的地址被写入一个指针类型的内存位置，且当前语句上下文无法100%确认该内存位置的所有引用都不会逃出当前栈帧，就会直接判定被取地址的局部变量存在逃逸风险，将其分配到堆上。
  这个分支的分析逻辑不会主动关联「x2本身是栈上变量、后续不会被传出当前函数」的全局分析结论，因此即使x2本体确实在栈上，依然会触发保守规则把i2移到堆。

注：两个结构体实例都标记为does not escape是符合预期的——编译器确实能确认这两个结构体本体没有跨栈帧引用，因此结构体本身的内存都分配在栈上，差异仅来自字段赋值路径的分析分支不同。

补充说明 #

这类保守判定是Go编译器逃逸分析的常规设计：为了保证分析效率和正确性，编译器不会对所有独立赋值语句做跨语句的全量引用追踪，仅在复合字面量构造、函数返回值判定等少数场景做关联分析，其余场景下只要存在指针逃逸的可能性，就会优先选择把变量分配到堆，避免出现悬空指针问题。

内容的提问来源于stack exchange，提问作者mishkamashka