Go中指针不会产生野指针，但滥用会导致nil panic等；禁用非必要，关键在明确取址、解引用和传递的意图与生命周期；勿返回局部变量地址，即使逃逸分析避免崩溃，仍掩盖语义问题。
Go 里指针不会导致传统意义上的“野指针”或“悬空指针”，但滥用仍会引发 nil panic、数据竞争、内存泄漏和语义混乱——关键不是禁用指针，而是让每一次取地址（&）、解引用（*）和传递都有明确意图和生命周期契约。
别返回局部变量地址，哪怕编译器“帮你逃逸”了
Go 编译器确实会做逃逸分析，把 return &x 中的 x 自动挪到堆上，避免崩溃。但这只是“不崩溃”，不是“写得对”。它掩盖了设计问题：调用方会误以为这个指针指向一个可长期持有的、独立管理的对象，而实际上它只是函数内部逻辑的副产品。
- 错误写法：
func getCounter() *int { x := 0 return &x // ✅ 不 panic，❌ 但语义模糊：谁负责重置？生命周期归谁？ - 更清晰的做法：
func newCounter() *int { return new(int) // 明确意图：新建一个可独立存在的计数器 } // 或直接返回值类型（如果无需共享状态） func getCounterValue() int { return 0 } - 检查是否逃逸：用
go build -gcflags="-m"看输出，确认变量分配位置，但别把它当“安全许可证”
循环中取地址必须隔离变量作用域
这是线上最常踩的坑之一：for 循环复用同一个变量，所有 &i 最终都指向循环结束后的最终值（比如 i == 3），导致切片里一堆指针全指向同一个数。
- 典型错误：
var ptrs []*int for i := 0; i < 3; i++ { ptrs = append(ptrs, &i) // ❌ 全是 &i，i 最后是 3 } - 两种安全写法（任选其一）：
// 方式1：在循环内重新声明（创建新作用域） for i := 0; i < 3; i++ { i := i ptrs = append(ptrs, &i) } // 方式2：用临时变量承接 for i := 0; i < 3; i++ { val := i ptrs = append(ptrs, &val) } - 注意：闭包中捕获循环变量也一样危险，
go func() { fmt.Println(&i) }()同样要隔离
接收指针参数前先判 nil，别假设调用方“一定传对”
Go 没有非空引用类型，*T 的零值就是 nil。一旦解引用就 panic，而 panic 往往发生在深层调用里，堆栈难读。防御性编程的核心动作就是：用之前先问一句“它是不是 nil？”
立即学习“go语言免费学习笔记（深入）”；
- 函数入口检查：
func processUser(u *User) error { if u == nil { return errors.New("user pointer is nil") } // ✅ 安全解引用 log.Printf("Processing %s", u.Name) return nil } - 结构体字段也要小心：
type Config struct { Timeout *time.Duration } // 使用前必须检查 if cfg.Timeout != nil { http.DefaultClient.Timeout = *cfg.Timeout } - JSON 反序列化尤其危险：
json.Unmarshal对*string字段，缺失或null都给nil，不是空字符串
并发场景下，指针 ≠ 共享，而是责任信号
拿到一个 *T，不等于你可以随便读写它。多个 goroutine 同时操作同一指针指向的数据，就是数据竞争的温床——即使没崩溃，结果也完全不可预测。
- 加锁不是唯一解，但必须有同步机制：
type Counter struct { mu sync.Mutex val int } func (c *Counter) Inc() { c.mu.Lock() defer c.mu.Unlock() c.val++ } - 更 Go 的方式是用 channel 传递所有权：
ch := make(chan *User, 1) ch <- &User{Name: "Alice"} go func() { u := <-ch // 此刻只有这个 goroutine 持有该指针 u.Name = "Bob" }() - 用
sync/atomic仅限基础类型指针（如*int32），且不能替代复杂逻辑中的锁；atomic.StorePointer和atomic.LoadPointer需配合unsafe.Pointer，门槛高、易出错，非必要不碰
最容易被忽略的，不是“怎么用指针”，而是“为什么这里需要指针”。每次写 & 或声明 *T 参数时，停下来问自己：是为了修改原值？为了节省拷贝开销？还是仅仅因为“别人都这么写”？后者，往往就是问题的起点。
