go 中 nil 是类型特定的零值而非空指针；仅对指针、切片、映射、通道、函数、接口合法；接口为 nil 当且仅当动态类型和值均为 nil；nil 切片可安全操作，nil 映射/通道操作会 panic。
Go 中 nil 不是“空指针”而是类型特定的零值
Go 的 nil 不是 C 风格的空地址，它没有统一底层表示；不同类型的 nil 不能直接比较，也不能混用。比如 *int 的 nil 和 chan int 的 nil 在内存中可能完全不同，只是语言约定它们都叫 nil。
常见错误现象：if x == nil 编译失败（如 x 是 map[string]int 类型变量），或看似能比但结果不符合预期（比如接口变量和底层指针都为 nil，但接口不等于 nil）。
-
nil只对指针、切片、映射、通道、函数、接口这六种类型合法；对 struct、array、string、bool、int 等类型写nil直接编译报错 - 接口变量为
nil的充要条件是：动态类型和动态值都为nil；只动态值为nil（如var r io.Reader = (*bytes.Buffer)(nil)）时，接口本身不为nil - 切片的
nil和空切片（[]int{}）行为几乎一致（len=0, cap=0, 底层数组为nil），但nil切片传给json.Marshal输出null，空切片输出[]
判断接口是否为 nil 时别直接用 == nil
接口变量内部是 (type, value) 二元组。当你把一个非空指针赋给接口，即使指针本身是 nil，接口也不为 nil——这是最常踩的坑。
示例：var err error = (*os.PathError)(nil)，此时 err != nil 为 true，但 *err panic。
立即学习“go语言免费学习笔记（深入）”；
- 正确判断方式是先类型断言再判空：
if e, ok := err.(*os.PathError); ok && e != nil - 更安全的做法是依赖标准库习惯：用
if err != nil判断错误是否发生，而不是深究它底层是不是指针nil - 自定义接口实现时，如果方法里会解引用接收者指针，务必在方法开头加
if p == nil { return }防 panic
nil 切片和 nil 映射的初始化差异影响并发安全
nil 切片可直接 append，但 nil 映射不能直接赋值——这个差异常被忽略，尤其在初始化逻辑分散时。
错误现象：m := map[string]int(nil); m["k"] = 1 panic: assignment to entry in nil map。
- 切片：未初始化的
nil切片可安全用于append、len、cap，无需预分配 - 映射：必须用
make(map[string]int)或字面量map[string]int{}初始化，否则所有写操作 panic - 通道：未初始化的
nil通道在select中永远阻塞，在send/receive中也永久阻塞——这可用于动态启用/禁用某个分支 - 并发场景下，
nil映射比空映射更危险，因为后者至少不会 panic；但nil通道在 select 中的阻塞行为反而可被有意利用
函数返回 nil 接口时，确保底层值和类型同时为空
函数返回接口类型时，如果只返回底层为 nil 的具体类型，接口本身可能非 nil，调用方 if x != nil 会误判。
典型例子：func newReader() io.Reader { return (*bytes.Buffer)(nil) }，该函数返回的 io.Reader 不是 nil，但任何方法调用都会 panic。
- 返回接口应显式返回
nil字面量：func newReader() io.Reader { return nil } - 若需条件返回，统一用指针或包装类型，避免裸指针转接口：
return &bytes.Buffer{}或return maybeReader()（其中maybeReader返回io.Reader类型） - 测试时别只测
!= nil，要测方法调用是否 panic，尤其是Read、Write这类核心方法
最容易被忽略的是：接口变量的 nil 性取决于运行时赋给它的第一个具体值，而不是声明方式。哪怕你写 var r io.Reader，后续谁赋值、怎么赋值，才真正决定它是不是 nil。
