go面试考内存模型核心是逃逸分析：变量逃逸看“escapes to heap”，闭包捕获、返回地址、interface{}传参、切片扩容等均导致逃逸；栈归goroutine管，堆归gc管；高频逃逸加重gc压力，需用sync.pool、预估容量等优化。
Go 面试里问内存模型，八成是在考逃逸分析、栈/堆分配逻辑、以及 GC 对它们的影响——不是让你背概念，而是看你能不能从 go build -gcflags="-m" 的输出里读懂编译器的真实意图。
怎么一眼看出变量逃逸了？
核心就看编译器是否打印 ... escapes to heap。逃逸不是 bug，但高频逃逸会拖慢性能、加重 GC 压力。
- 闭包捕获局部变量：哪怕只读，
func() { return x }中的x通常逃逸（因为可能被返回后长期持有） - 返回局部变量地址：
return &s[0]或return &v—— 栈上变量生命周期结束，必须挪到堆 - 传入 interface{} 或空接口：
fmt.Println(s)中的s很可能逃逸（底层要反射+堆分配） - 切片追加后容量不足触发扩容：
append(s, x)若原cap不够，新底层数组必然在堆上分配
栈和堆到底谁管什么？
栈归 goroutine 自己管，每个 goroutine 启动时配一个初始 2KB 栈（Go 1.14+），按需分裂扩容；堆归 runtime 和 GC 管，所有跨函数生命周期的对象都落这儿。
- 栈上变量：函数返回即销毁，零 GC 开销，比如
var i int = 42（没被取地址、没传 interface、没逃逸） - 堆上对象：哪怕是个
int，只要被new(int)或作为结构体字段被逃逸引用，就进堆 - 注意陷阱：
make([]int, 0, 100)底层数组在堆，但切片头（struct{array *int; len, cap int}）本身在栈——头不逃逸，数组逃逸
GC 怎么跟内存分配联动？
三色标记 + 混合写屏障是关键，但面试真问细节，重点其实是「小对象多 → GC 频繁 → STW 时间感知变长」这个链路。
立即学习“go语言免费学习笔记（深入）”；
- 每秒分配 10MB 小对象，比分配 10MB 大对象更伤 GC：前者产生上千个独立堆块，标记扫描耗时翻倍
- 避免方式：复用对象（
sync.Pool）、预估容量（make([]T, 0, N)减少扩容）、减少 interface{} 泛化调用 - 验证手段：
GODEBUG=gctrace=1 ./yourapp看每次 GC 的标记时间、堆大小变化；go tool pprof查 allocs/inuse_objects
真正难的不是记住“逃逸规则”，而是看到一段业务代码（比如循环中不断 json.Marshal 请求体），能立刻反应出：这里 map[string]interface{} 会逃逸、[]byte 底层数组会反复堆分配、GC 压力集中在请求高峰——然后给出池化或结构体重用的具体改法。这才是面试官想确认的“模型感”。
