nil 指针解引用（如 *p、p.Field）会 panic；仅指针、切片、映射、通道、函数、接口可为 nil，int/string/struct 等只有零值；struct 变量永不为 nil，接口 nil 需类型和值均 nil；解引用前须判空。
空指针本身不会出问题，nil 是 Go 合法的零值；真正导致崩溃的是对 nil 指针的 ** 解引用操作 **——比如 *p、p.Field、p.Method()，这些会立刻触发 panic: invalid memory address or nil pointer dereference。
哪些类型可能为 nil？哪些不可能？
Go 中只有少数类型支持 nil：指针（*T）、切片（[]T）、映射（map[K]V）、通道（chan T）、函数（func()）、接口（interface{}）。其他如 int、string、struct{} 等 ** 没有 nil 概念，只有零值 **（0、""、struct{}{}）。
-
struct类型变量永远不为nil，所以if s == nil是语法错误 - 接口是否为
nil取决于其底层类型和值是否都为nil；var u *User; var i interface{} = u时，i != nil（类型存在，值为nil），直接i.(fmt.Stringer)再调用方法仍会 panic - 切片虽可
nil，但len(s)、cap(s)安全；隐患在于传给函数后，若函数内部假设底层数组非空（如直接访问s[0]），就会崩
解引用前必须判空的典型场景
不是所有指针使用都需要判空，但以下操作一旦面对 nil 就必然 panic：
- 结构体指针字段访问：
u.Profile.Name→ 若u.Profile == nil，直接 panic - 方法调用：
u.Save()（u是*User）→ 方法接收者为nil时仍可调用，但内部若访问字段就会崩 - 映射写入：
m["key"] = value→ 若m == nil，panic - 通道收发：
或ch →ch == nil时阻塞并 panic - 函数调用：
f()→ 若f == nil，panic
推荐写法是「早失败」：
func (u *User) FullName() string { if u == nil { return ""} if u.Profile == nil {return u.Name} return u.Name +" ("+ u.Profile.Nickname +")" }构造与返回指针时的常见陷阱
很多 panic 源于函数返回了未初始化或意外为 nil 的指针，而调用方没检查：
立即学习“go 语言免费学习笔记（深入）”；
- 不要返回局部变量地址（即使逃逸分析让它“能跑”）：
func bad() *int { x := 42; return &x}—— 语义模糊，易误导，应改用显式堆分配或返回值 - 构造函数应明确失败路径：
func NewUser(name string) (*User, error) {if name == ""{ return nil, errors.New("name required") } return &User{Name: name}, nil }调用方必须检查
err，不能假设返回值非nil - 避免将
nil指针赋给接口后直接使用：var w io.Writer = (*bytes.Buffer)(nil)表面看是nil，但w.Write([]byte{})会 panic；应确保接口底层值有效，或在方法内自行判空
最常被忽略的一点：嵌套指针链（如 u.Profile.Address.Street）要逐层判断，而不是只查第一层；工具 如 go vet 和静态分析器（staticcheck）能帮你发现部分漏判，但逻辑责任仍在人手——只要涉及解引用，就默认它可能 nil，除非你 100% 控制了它的生命周期和初始化路径。
