返回 slice 通常不触发堆分配，因为 slice header（24 字节三字段结构）可栈分配；逃逸分析仅针对 header，底层数组是否在堆取决于 make 或 append 是否扩容。
函数返回 slice 时，绝大多数情况下不触发堆分配，除非你显式取它的地址（比如 &s）或传给可能逃逸的函数。
为什么返回 slice 通常不分配堆内存
slice 本身是一个三字段结构体（array 指针、len、cap），值大小固定（24 字节）。Go 编译器在逃逸分析中会判断：只要这个 slice 值没被取地址、没被存入全局变量、没被传给接口或可能长期持有的函数（如 goroutine、map、channel 写入），它就全程驻留在栈上。
即使底层数组在堆上（比如通过 make([]int, 0, 100) 分配），slice 头部（header）仍可栈分配 —— 它只是个指向堆数组的指针+长度+容量。
- 常见误判场景：
return &s→ 强制逃逸到堆；return append(s, x)若扩容，底层数组新分配在堆，但 slice header 仍可栈驻留 - 关键点：逃逸分析对象是 slice header，不是底层数组
- 验证方式：
go build -gcflags="-m -l"看编译输出是否含moved to heap
append 后返回 slice 的内存行为
返回值本身仍是栈上的 header，但底层数组是否在堆，取决于 append 是否触发扩容：
- 容量充足时：
s = append(s, x)只改len，底层数组不变，无新分配 - 容量不足时：调用
runtime.growslice，分配新底层数组（堆上），复制旧数据，再追加 → 底层数组搬迁，但新 slice header 仍栈分配 - 注意：
append返回的是新 header，原 header 不再有效；若函数内多次append并返回，每次扩容都可能产生一次堆分配
容易踩的坑：以为“返回 slice 就等于返回堆对象”
这种误解会导致过早优化（比如加 *[]T 指针返回）或误判 GC 压力。真实瓶颈往往不在 slice header 分配，而在底层数组反复扩容复制。
- 典型错误：函数内
s := make([]int, 0); for i := range data { s = append(s, i) }→ 每次扩容都新分配底层数组，header 始终栈上，但复制开销大 - 正确做法：预估长度，
s := make([]int, 0, len(data))，避免多次 realloc - 更隐蔽的坑：把返回的 slice 传给
fmt.Printf("%v", s)或json.Marshal，这些函数接收interface{}，可能触发 header 逃逸（取决于具体实现和 Go 版本）
最常被忽略的是：底层数组的生命周期不由 slice header 控制，而由所有引用它的 slice 共同决定。哪怕 header 已出作用域，只要还有别的 slice 持有同一 array 指针，那块堆内存就不会被回收。
