用反射判断[]int是nil还是空切片，需先检查kind()为reflect.slice，再调用isnil()：true为nil切片，false时结合len()==0判断是否为空切片。
怎么用反射判断 []int 是 nil 还是空切片
直接看 reflect.Value.Kind() 没用——两者都是 reflect.Slice。关键得查底层指针是否为 nil，而反射里得靠 reflect.Value.IsNil()，但它只对 slice、map、chan、func、ptr、unsafe.Pointer 有效。
实操建议：
-
reflect.ValueOf(x).Kind() == reflect.Slice先确认是切片类型 - 再调用
reflect.ValueOf(x).IsNil()：返回true表示是 nil 切片（底层 ptr == nil）；false可能是空切片，也可能有元素 - 若
IsNil()为false，再用Len()判断长度是否为 0，才能确认是不是空切片
nil 切片和 len(s) == 0 的行为差异在哪
这是最常踩坑的地方：两者都满足 len(s) == 0 和 cap(s) == 0，但底层内存状态完全不同。nil 切片的底层数组指针是 nil，空切片则指向一个真实（哪怕长度为 0）的底层数组。
影响很实际：
立即学习“go语言免费学习笔记（深入）”；
- 向 nil 切片
append会自动分配内存，没问题；向空切片append也可能复用底层数组，但若 cap 不足仍会扩容 -
json.Marshal对两者输出不同：nil切片序列化为null，空切片是[] - 传参时若函数内部做了
if s == nil判断，空切片会绕过这个分支，可能引发逻辑偏差
不用反射，纯语言层面怎么安全判空又区分 nil
多数场景其实不需要反射——Go 的类型系统允许直接比较切片和 nil，但必须注意变量类型是否确定。
常见写法与陷阱：
- 直接写
s == nil只在s是具体切片类型（如[]string）时合法；若s是interface{}或泛型参数，则编译报错 - 泛型函数中可用约束
~[]T，然后用any(s) == nil？不行，会 panic；正确方式是先转回具体类型或用反射 - 最稳妥的通用判空函数（不依赖反射）：接收
interface{}后用类型断言 +== nil，但只能覆盖已知类型，无法穷举
为什么 reflect.Value.IsNil() 对非指针类型 panic
因为 IsNil() 语义上只适用于“可能为 nil 的类型”，而普通值类型（如 int、struct{}）根本不可能为 nil。一旦你对 int 类型的 reflect.Value 调用它，就会触发 panic: call of reflect.Value.IsNil on int Value。
所以必须加保护：
- 调用前先检查
v.Kind()是否属于reflect.Slice、reflect.Map等六种允许类型 - 别对
v.Elem()后的结果盲目调用IsNil()——如果原值不是指针，Elem()就会 panic - 典型错误链：
reflect.ValueOf(&s).Elem().IsNil()看似绕过类型限制，但如果s本身是值类型，Elem()返回的是可寻址副本，依然不能IsNil()
真正难的不是写对一次判断，而是确保所有入口——包括 interface{} 参数、泛型函数、JSON 反序列化后的字段——都统一处理了 nil 和空的语义差异。稍不注意，nil 在某层被转成空切片，后面就再也追不回来了。
