17370845950

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} 是完全合法的状态。

• 访问前逐层判空：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 出现得既合理又隐蔽。养成“声明即检查、接收即防御、返回即担保”的习惯，比记住所有规则更管用。