Go中指针危险点有三：nil解引用必panic，需显式判空；循环变量地址被复用致数据错乱，应堆分配；map存指针并发读写引发竞态，须额外同步字段或改用封装方法。
Go 里指针本身不危险，但 nil 解引用、循环变量地址复用、并发裸共享——这三个地方一踩就 panic 或数据错乱。
解引用前不判 nil 就 panic
这是最常见、最直接的崩溃原因：对 nil 指针做 * 操作或调用方法，立刻触发 panic: runtime error: invalid memory address or nil pointer dereference。
- 函数入参是
*User？第一行就得检查：if u == nil { return fmt.Errorf("user is nil") } - 结构体字段是
*string？访问前必须写：if u.MiddleName != nil { fmt.Println(*u.MiddleName) } - 从
map[string]interface{}取值后断言为*Config？不能跳步：if c, ok := data.(*Config); ok && c != nil { ... } - 接口变量赋了
nil指针（如var u *User; i := interface{}(u)），i == nil是 false —— 正确判断是reflect.ValueOf(i).IsNil()，但更推荐设计上避免这种赋值
for 循环中取局部变量地址导致所有指针指向同一值
在循环里反复用同一个变量名创建结构体再取地址，Go 会复用栈空间，结果切片或 map 里所有指针都指向最后一次迭代的值。
data := []string{"Alice", "Bob"}
var people []*Person
for _, name := range data {
p := Person{Name: name} // 栈上变量，地址被复用
people = append(people, &p) // ❌ 全部指向同一个地址
}
- 正确做法：每次迭代直接在堆上分配，用
&Person{Name: name} - 或者用临时变量 + 显式取地址，但需确保该变量生命周期足够长（通常只有堆分配才安全）
- 验证方式：打印每个元素地址：
fmt.Printf("%p\n", people[i])，若全一样就是踩坑了
map 中存指针却忽略并发读写风险
把 *User 存进 map[string]*User，再用多个 goroutine 同时修改 users["a"].Name，即使 map 本身加了锁，也拦不住对底层结构体字段的竞态访问。
立即学习“go语言免费学习笔记（深入）”；
- 单纯给 map 加
sync.Mutex只保护 map 的增删改查，不保护*User指向内容的读写 - 真正要保护的是结构体字段：要么在访问
users["a"]后，用另一个锁保护其字段；要么改用 channel 传递数据，而非共享指针 - 更稳妥的做法是避免在 map 中存可变指针；若必须共享，优先封装成带锁的方法（如
u.SetName()），把同步逻辑收口
返回局部变量地址编译器虽拦截但语义易错
Go 编译器会自动将“需要逃逸”的局部变量分配到堆上，所以 return &i 通常不会崩溃，但容易让人误以为“返回栈地址也没事”，从而写出语义错误的代码。
- 例如函数内定义
var u User再return &u，虽然能跑通，但掩盖了所有权模糊的问题 - 应明确意图：若构造失败，返回
(nil, err)；若成功，返回堆上新对象地址，且最好通过工厂函数（如NewUser()）封装 - 用
go build -gcflags="-m"查看变量是否逃逸，不是为了绕过检查，而是确认你的设计是否符合预期
指针真正的复杂点不在语法，而在谁负责初始化、谁拥有生命周期、谁保证非空——这些契约一旦模糊，工具和编译器都救不了。
