Go指针变量分配位置取决于作用域和逃逸分析，而非指针本身；其指向的数据位置由创建方式决定；逃逸分析是编译期自动判断变量是否需堆分配的关键机制。
Go指针本身不特殊，它就是一个存地址的变量，大小固定（64位系统是8字节），分配位置取决于作用域和逃逸分析，而不是“因为是指针所以放堆上”。真正影响性能和行为的，是它指向的数据在哪、生命周期多长。
指针变量存在哪？看作用域和逃逸
指针变量和其他变量一样，遵循Go统一的内存分配规则：
- 函数内声明的局部指针，比如 var p *int，只要没被返回、没存进全局变量或堆对象，就分配在栈上
- 一旦编译器发现这个指针的值（即它指向的地址）会被函数外使用，比如 return &x，那 x 就会逃逸到堆，p 本身也可能被移到堆上（取决于是否被外部引用）
- 包级指针变量（如 var globalP *string）直接放在数据段，属于静态区，程序启动时就存在，结束时才释放
指针指向的数据在哪？看创建方式
指针的值是地址，这个地址指向的内容，由创建它的方式决定：
- &x：x 本身在哪，地址就指向哪。x 在栈 → 指向栈；x 因逃逸在堆 → 指向堆
- new(T) 或 &T{}：明确在堆上分配内存，返回的指针一定指向堆
- 切片/Map/Channel 的元素地址：底层数据总在堆上，所以取到的指针也指向堆
- 栈上的指针完全可以指向堆数据（很常见），堆上的指针也可以指向其他堆数据（比如结构体字段是指针）
逃逸分析才是关键裁判
Go不靠程序员手动指定栈或堆，而是由编译器在编译期做逃逸分析，判断变量是否“逃出”当前作用域：
- 如果一个局部变量的地址被返回、赋给全局变量、传入 goroutine 或存进 map/slice，它就必须堆分配
- 命令 go build -gcflags="-m -l" 可以查看逃逸详情，比如 “moved to heap” 或 “escapes to heap”
- 逃逸不是坏事，是安全机制：避免函数返回后访问已销毁的栈内存
值类型 vs 指针类型：别只看大小
选值传递还是指针传递，不能只看结构体大不大：
- 小结构体（如两个 int 字段）值传递开销极小，栈上拷贝快，GC 无压力
- 大结构体用指针可避免拷贝，但每个指针本身带来 8 字节开销，且若指向堆，会增加 GC 扫描负担
- 更关键的是语义需求：需要修改原值？要实现某个接口（如 io.Writer）？方法接收者是否统一？这些常比内存数字更重要
基本上就这些。理解指针和内存的关系，核心是分清“指针变量在哪”和“它指向的数据在哪”，再把逃逸分析当作背后的自动调度员——它不动声色，但决定了大部分实际布局。
