nil指针是合法零值，解引用才panic；interface含nil指针时不等于nil；访问嵌套指针需逐层判空或封装安全访问器。
nil 指针不是“空对象”，而是未指向任何内存地址的指针值——它本身合法，解引用才 panic。
为什么 var p *int 不报错，但 *p 会崩溃？
Go 中 nil 是指针类型的零值，声明即得，不分配内存。它和 C 的 NULL 类似，但更严格：你不能对它做任何读写操作（*p、p.Method()、p.Field），否则立刻触发 panic: runtime error: invalid memory address or nil pointer dereference。
-
nil指针本身可安全比较：p == nil是合法且推荐的第一步 - 结构体指针接收者方法里，
u *User可能为nil，所以func (u *User) GetName() string内部仍需先判if u == nil - 函数返回指针时，若失败应返回
nil, err，而不是只返回nil—— 调用方必须先检查err != nil，再用指针
接口里藏了个 nil 指针，为什么 i == nil 却是 false？
这是最常踩的坑：interface{} 是“类型 + 值”的组合。只要动态类型存在（哪怕值是 nil），接口变量就不等于 nil。
var p *string = nil
var i interface{} = p
fmt.Println(i == nil) // false —— 类型是 *string，值是 nil
fmt.Println(p == nil) // true
- 错误写法：
if err != nil { return }看似稳妥，但如果err是*MyError类型且为nil，赋给error接口后，err != nil仍为true，但err.Error()会 panic - 正确做法：自定义错误类型时，确保
Error()方法不依赖任何可能为nil的字段；返回错误统一用return nil，而非return (*MyError)(nil) - 调试时可用
reflect.ValueOf(i).IsNil()辅助判断，但生产代码应从设计上避免把裸nil指针塞进接口
结构体字段是 *string，怎么安全取值？
嵌套指针字段天然易空，不能靠“应该有”来假设。比如 User{Name: nil} 是完全合法的状态。
立即学习“go语言免费学习笔记（深入）”；
- 访问前逐层判空：
if u != nil && u.Name != nil { fmt.Println(*u.Name) } - 封装安全访问器，避免重复逻辑：
func (u *User) SafeName() string { if u == nil || u.Name == nil { return "" } return *u.Name } - 构造时明确语义：用
NewUser(name string)强制初始化关键字段，或文档注明某字段“允许为nil”，让调用方知情 - 别用
json.Unmarshal直接填入含指针字段的结构体后就直接解引用——JSON 中缺失字段会导致对应指针为nil
真正危险的从来不是 nil 本身，而是你以为它“不会是 nil”的那个瞬间。HTTP 客户端返回 *http.Response、数据库查询返回 *User、JSON 解析生成 *Config……这些地方，nil 出现得既合理又隐蔽。养成“声明即检查、接收即防御、返回即担保”的习惯，比记住所有规则更管用。
