goroutine 栈空间不存指针指向的数据
Go 的 goroutine 栈是独立且自动管理的，但栈上分配的对象（比如局部 &v）生命周期只到函数返回。一旦函数退出，栈帧回收，指针若还被其他 goroutine 持有，就变成悬垂指针——不过 Go 编译器会阻止这种逃逸，强制分配到堆。
常见错误现象：panic: runtime error: invalid memory address or nil pointer dereference 看似指针问题，实则是对象已被回收或未正确初始化。
- 用
go tool compile -m查看变量是否逃逸：如果出现... moves to heap，说明该值不会留在栈上 - 不要手动“假设”某个
*int一定在栈上——Go 不保证，也不该依赖 - 跨 goroutine 传递指针时，确保所指对象生命周期 ≥ 接收方使用时间；最稳妥是传值或用
sync.Pool管理临时对象
new() 和 & 操作符分配位置由逃逸分析决定
new(T) 总是在堆上分配，返回 *T；而 &v（v 是局部变量）是否逃逸，取决于编译器判断——不是语法决定，而是数据流分析结果。
使用场景：写高性能服务时，频繁小对象逃逸会加重 GC 压力；但为避免悬垂引用而强制堆分配，又是必要取舍。
立即学习“go语言免费学习笔记（深入）”；
-
var v int; p := &v→ 若p被返回或传入 goroutine，v逃逸到堆 -
p := new(int)→ 直接堆分配，无逃逸分析参与，适合明确需要共享生命周期的场景 - 对比
make([]int, 10)：底层数组总在堆上，但 slice header 可能栈上——别混淆 header 和 backing array
goroutine 栈大小动态伸缩，但和指针语义无关
Go 初始栈约 2KB，按需增长（最大默认 1GB），但这只是执行上下文空间，不影响指针所指内存的位置或生命周期。有人误以为“栈大了就能多存指针”，其实完全无关。
性能影响：栈扩容是昂贵操作（需复制旧栈、调整所有指针），但触发条件是深度递归或超大局部变量，不是因为用了多少 *T。
- 避免在循环中反复声明大数组并取地址，例如
for i := range xs { buf := [4096]byte{}; p := &buf }→ 极易触发逃逸+栈增长 - 用
runtime/debug.SetMaxStack只影响 panic 时栈追踪深度，不控制运行时栈大小 - goroutine 间通过 channel 传指针？可以，但接收方必须清楚该指针是否仍有效——比如发送方函数已返回，则危险
pprof 分析真实内存归属时，别被“stack”字眼误导
用 go tool pprof -alloc_space 看到的 “stack” 标签，实际指“分配点在栈帧内”，不是说内存本身在栈上。Go 的运行时报告里，“stack” 是源码位置标记，不是内存区域分类。
容易踩的坑：看到 pprof 显示某 *struct{} 分配在 “stack”，就以为它很快被回收——错。只要逃逸了，它就在堆上，和栈帧无关。
- 查内存归属，优先看
-inuse_space+top，配合web图看调用链，而不是盯着标签字面意思 -
runtime.ReadMemStats中的HeapAlloc才反映真实堆内存占用，StackInuse仅表示当前所有 goroutine 栈总开销（含未使用预留页） - 调试时加
GODEBUG=gctrace=1，观察每次 GC 是否清理了预期对象——如果没清，大概率是某个 goroutine 还持有指针
真正难的是判断指针背后的数据到底活在哪：不是看你怎么写 &，而是看它会不会逃逸、谁还在引用、GC 根是否还连着。这些没法靠经验猜，得靠 -m 和 pprof 验证。
