Go 中 nil 是类型明确的零值，需按类型语义安全处理：指针解引用前必判 nil；接口需双检 i == nil 或 reflect.ValueOf(i).IsNil()；error 用 err != nil 判断；切片/map/channel 虽可传参但操作前需验证有效性。
Go 里 nil 不是万能的“空值占位符”，而是类型明确的零值。安全处理 nil 的核心不是回避它，而是理解它在不同类型的语义，并建立可落地的检查习惯。
指针类型：解引用前必判 nil
对 *T 类型指针直接取值（*p）或调用方法时，若 p == nil，会立即 panic。这不是逻辑错误，而是运行时崩溃。
- 函数接收指针参数时，第一行就做 if p == nil { return ... } 检查
- 结构体方法定义为指针接收者时，方法体内仍需判断 if u == nil，否则
var u *User; u.Greet()会挂掉 - 避免返回局部变量地址，更不要返回未初始化的指针（如
var u *User; return u）
接口类型：nil 不等于“底层值 nil”
interface{} 的零值是 nil，但 var u *User; var i interface{} = u 中，i 不为 nil（类型存在，值为 nil），直接 i == nil 判断失败。
- 需要同时检查： if i == nil || reflect.ValueOf(i).IsNil()
- 更推荐设计上不把可能为 nil 的指针赋给接口；优先用值类型或显式包装
- 如果必须传递，文档注明“允许传 nil”，并在使用处加双保险判断
error 类型：nil 是“无错误”的信号
error 是接口，其零值就是 nil。所以 err != nil 是 Go 错误处理的基石判断，但它本身不危险——只是普通比较。
立即学习“go语言免费学习笔记（深入）”；
- 永远不要忽略 err 返回值，哪怕只写 if err != nil { log.Printf("ignored: %v", err) }
- 用 errors.Is(err, os.ErrNotExist) 替代
err == os.ErrNotExist，兼容包装链 - 自定义错误类型时，确保 Error() string 方法不依赖任何可能为 nil 的字段（比如避免访问 u.Name 而 u 是 nil）
切片、map、channel：nil 可安全传参，但不能直接操作
nil 切片可 len()、cap()、range，但不能索引（s[0] panic）；nil map 不能赋值（m["k"] = v panic）；nil channel 不能收发（ 阻塞或 panic）。
- 新建后立即初始化： s := make([]int, 0) 或 m := make(map[string]int)
- 函数接收 map/slice 参数时，若逻辑允许空，用 len(s) == 0 或 len(m) == 0 判断，而非
s == nil - 用 go vet 和静态分析工具（如
staticcheck）自动捕获常见 nil 解引用场景
基本上就这些。nil 不可怕，可怕的是假设它“安全”或“不存在”。养成声明即初始化、使用前必检查、返回前保非空的习惯，比任何技巧都管用。
