Go 指针不会出现传统野指针，因其禁止栈变量地址逃逸、无指针算术、零值初始化为nil、GC保障内存安全；主要风险是nil解引用导致panic，需尽早检查并明确指针可空性契约。
为什么 Go 的指针不会出现传统意义上的“野指针”
Go 编译器禁止取局部变量地址后逃逸到函数外（除非显式分配在堆上），且运行时有内存安全检查，所以你写不出 C 那种返回栈变量地址后继续解引用的典型野指针代码。真正要防的是 nil 指针解引用导致 panic，以及误用未初始化指针。
- Go 中所有变量声明即零值初始化：
var p *int的p初始值是nil，不是随机地址 - 没有指针算术（
p++、p + 1等非法），无法手动构造非法地址 - GC 会追踪所有指针，不会提前回收仍在使用的堆对象
哪些操作会触发 panic: "invalid memory address or nil pointer dereference"
这是 Go 中最常见、也最容易被忽略的指针错误。只要对 nil 指针做解引用（*）或方法调用，就会立即 panic。
type User struct {
Name string
}
func (u *User) Greet() string {
return "Hello, " + u.Name // 如果 u == nil，这里 panic
}
func main() {
var u *User
fmt.Println(u.Greet()) // panic!
}
-
u.Name、*u、u.Method()都要求u != nil - 结构体字段赋值如
u.Name = "Alice"同样 panic - 但
if u == nil、fmt.Printf("%p", u)是安全的
如何安全地解引用和传递指针参数
关键不是“避免用指针”，而是明确每个指针变量的生命周期和可空性契约。Go 标准库和主流项目普遍接受 nil 指针作为合法输入，只要方法内部做判断。
- 接收指针参数的函数，应文档化是否接受
nil；若不接受，开头加if p == nil { panic("p must not be nil") } - 返回指针的函数（如
json.Unmarshal），调用方必须检查错误，而非假设指针非空 - 用
new(T)或&T{}显式初始化，比var p *T更明确意图 - 切片、map、channel 本身是引用类型，传参无需加
*；给它们加指针通常是设计信号（例如想替换整个底层数组）
容易被忽略的边界场景：嵌套指针与接口中的指针
指针安全问题常藏在间接层里：比如结构体字段是指针、接口值底层是 *T、或者通过反射获取地址。
立即学习“go语言免费学习笔记（深入）”；
-
type Config struct { DB *sql.DB }—— 忘记初始化DB字段，后续调用c.DB.Query()panic -
var i interface{} = &User{}; u := i.(*User)安全，但i = nil; u := i.(*User)会 panic（类型断言失败，不是 nil 解引用） -
reflect.ValueOf(&x).Elem().Interface()若&x是nil，Elem()会 panic - JSON 反序列化时，字段为
*string，如果 JSON 中该字段缺失或为null，结果是nil指针 —— 使用前必须检查
nil 当成有效值一路传下去，直到某个深层调用突然解引用。越早检查、越靠近数据源头验证，越不容易漏。 
