Go指针易引发内存泄漏、goroutine泄漏、data race、逃逸分析失控及nil解引用panic，应优先使用值语义，仅在必要时用指针。
指针导致内存泄漏和 goroutine 泄漏
Go 的垃圾回收器无法回收仍被指针引用的对象，哪怕逻辑上已不再需要。常见于缓存、全局 map 或 channel 中存储了指向大结构体的指针，而忘记清理或未设过期机制。
- 向
sync.Map或全局map[string]*BigStruct插入后长期不删除，*BigStruct及其引用的子对象持续驻留内存 - 启动 goroutine 时传入局部变量地址：
go func() { use(ptrToLocalVar) // 即使函数返回，ptrToLocalVar 所指内存仍可能被 goroutine 持有 }()若该 goroutine 运行时间远超原函数生命周期，就构成隐式内存泄漏 - channel 发送指针值后，接收方未及时处理或丢弃，发送方又继续发送新指针——缓冲区堆积大量不可达但未回收的对象
并发读写引发 data race
多个 goroutine 同时通过不同指针修改同一底层数据，且无同步保护，是 Go 中最典型的 data race 场景。go build -race 会报类似 Read at 0x00c000123456 by goroutine 7 的错误。
- 共享一个
*sync.Mutex实例却在不同 goroutine 中各自 new 出新指针：mu := &sync.Mutex{}→ 每次都新建，锁失效 - 结构体字段为指针类型（如
data *[]byte），两个 goroutine 分别解引用并追加元素：*s.data = append(*s.data, x)→ 底层数组扩容后旧地址失效，另一 goroutine 写入野指针 - 使用
unsafe.Pointer强转并并发修改，绕过 Go 类型系统检查，race detector 也难以捕获
逃逸分析失控与堆分配激增
编译器发现变量地址被外部获取（如返回局部变量地址、传给 goroutine、存入切片/映射），就会强制将其分配到堆上。滥用指针会让本可栈分配的小对象全部逃逸。
- 函数返回局部变量地址：
func bad() *int { x := 42 return &x // x 必然逃逸到堆，即使只用一次 }相比直接返回int，多一次堆分配+GC 压力 - 切片元素存指针而非值：
[]*Item对比[]Item—— 前者每个*Item独立堆分配，后者整体连续分配，缓存友好性差一个数量级 -
json.Unmarshal接收*struct{}是必须的，但若对小结构体（如type ID struct{ N int }）也坚持传*ID，反而增加间接寻址开销
nil 指针解引用 panic 难以定位
Go 不做空指针防护，nil 指针解引用直接 panic，堆栈常只显示 panic: runtime error: invalid memory address or nil pointer dereference，不指明具体字段或调用链。
立即学习“go语言免费学习笔记（深入）”；
- 嵌套指针层级深（如
a.b.c.d.E.Name），任一环节为nil都会导致 panic，但运行时无法静态检查 - 方法接收者为指针类型，但调用方传入
nil：如果方法内未做if p == nil判断，就直接访问字段或调用其他方法，panic 发生点远离原始赋值处 - 第三方库返回
*T，文档未明确是否可能为nil，使用者忽略判空，上线后偶发 crash
struct{} 比 *struct{} 更轻、更安全、更易推理。 
