指针变量本身在栈还是堆上由逃逸分析决定，而非指针类型；局部指针如var p *int未逃逸时在栈上分配（仅8字节地址），逃逸时才分配到堆；其指向的数据位置取决于创建方式（如&x随x位置，new(T)必在堆）。
指针变量本身在栈还是堆上，由逃逸分析决定
Go 不会因为变量是指针类型就强制分配到堆上。var p *int 这样的局部指针，只要没逃逸，就和普通 int 一样在栈上分配——它只是个 8 字节（64 位系统）的地址容器。
真正触发堆分配的是“指针被外部持有”这个行为，比如函数返回 &x、赋值给全局变量、传入 goroutine 或 map 等。这时编译器通过逃逸分析把原变量（如 x）挪到堆上，确保地址有效。
-
func f() *int { x := 42; return &x }→x逃逸，分配在堆 -
func f() { x := 42; p := &x; fmt.Println(*p) }→x和p都在栈，不逃逸 - 用
go tool compile -gcflags="-m" main.go可查看逃逸详情
指针指向的数据位置，取决于创建方式而非指针声明
指针变量的存储位置（栈/堆）和它指向的数据位置是两回事。一个栈上的指针完全可以指向堆数据，反之亦然。
常见创建方式对应的数据位置：
立即学习“go语言免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
-
&x：指向x的实际位置（x在哪，它就在哪） -
new(T)或&T{}：一定在堆上分配，返回堆地址 -
make([]int, 10)底层数据在堆，所以&slice[0]指向堆内存 - 结构体字段如果是值类型，嵌入在结构体内存中；如果是指针，则指向别处
函数参数传指针时，注意局部变量地址暴露风险
传指针本身没问题，但若在函数内取局部变量地址并返回或保存，就可能引入悬空引用隐患——虽然 Go 的逃逸分析会兜底把它挪到堆，但开发者得意识到这是隐式开销。
- 错误写法：
func bad() *string { s := "hello"; return &s }→ 编译器强制堆分配，但语义上易误导 - 更清晰的写法：
func good() *string { s := new(string); *s = "hello"; return s } - 如果只是临时读取，避免无谓取地址：
func read(s string) { fmt.Println(s) }比func read(s *string)更轻量
nil 指针解引用 panic 是运行时行为，不是编译错误
var p *int 声明后值为 nil，此时 *p 会直接 panic，错误信息是 panic: runtime error: invalid memory address or nil pointer dereference。
这不是编译期能捕获的问题，必须靠逻辑判断或工具辅助：
- 调用前检查：
if p != nil { *p = 42 } - 用
go vet可发现部分明显未初始化就解引用的模式 - 结构体字段指针尤其容易漏判，比如
type User struct{ Name *string }，Name默认是nil
真正容易被忽略的是：指针变量的作用域边界和它所指向数据的生命周期边界并不重合。一个函数内声明的指针可能长期存活，但它指向的东西是否还有效，得看那个东西自己有没有逃逸、有没有被 GC 回收——这层间接性，是理解 Go 指针行为的关键落点。
