17370845950

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 错误处理的基石判断，但它本身不危险——只是普通比较。

• 永远不要忽略 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 不可怕，可怕的是假设它“安全”或“不存在”。养成声明即初始化、使用前必检查、返回前保非空的习惯，比任何技巧都管用。