应统一用len(s) == 0判断切片是否为空，而非s == nil；因nil切片和空切片len均为0且len()调用安全，而s == nil仅适用于具体切片类型、在interface{}或泛型中会编译失败，且json序列化语义不同。
判断切片是否为空，直接用 len(s) == 0 就行，别纠结 s == nil —— 后者只在极少数需要区分“未初始化”和“已初始化但空”的场景才有意义。
为什么 len(s) == 0 是通用判空标准
所有合法切片（包括 nil 切片和空切片）的长度都是 0，len() 对两者都安全、不 panic、语义明确：
-
var s []int→len(s)返回 0 -
s := []int{}或s := make([]int, 0)→len(s)同样返回 0 - 对
nil切片调用len()是 Go 语言明确定义的合法操作，不会崩溃
s == nil 只适用于具体类型变量，且容易误用
这个判断看似直观，但实际限制多、风险高：
- 仅当变量是明确的切片类型（如
[]string）时才能写s == nil；若它是interface{}或泛型参数（如func F[T any](v T)），直接比较会编译失败 - JSON 序列化时，
nil切片转成null，空切片转成[]—— 如果你本意只是“没数据”，却用了s == nil做分支，API 行为可能意外不一致 - 有人误以为
len(s) == 0不够“严格”，其实它才是最贴近业务语义的：用户关心的是“有没有元素”，不是“底层数组指针是不是零”
泛型或 interface{} 场景下怎么安全判空
当你无法静态知道切片类型（比如函数接收 interface{} 或泛型参数），必须用反射，但要注意陷阱：
- 别直接调
reflect.ValueOf(v).IsNil()—— 对非指针类型切片会 panic - 正确做法是先确认类型，再查长度：
func IsSliceEmpty(v interface{}) bool { rv := reflect.ValueOf(v) if rv.Kind() != reflect.Slice { panic("not a slice") } return rv.Len() == 0 } - 注意：这个函数对
nil切片也返回true（因为reflect.ValueOf(nil_slice).Len()是 0），符合“判空”需求；如果真要区分nil和空，得额外加!rv.IsValid()判断，但极少需要
别踩这些坑
几个高频翻车点：
- 用
s == nil替代len(s) == 0在 HTTP handler 或 JSON API 中做逻辑分支，结果前端收到null而不是[]，导致 JS 解析报错 - 在泛型函数里写
v == nil，编译不过还一脸懵 - 以为
make([]int, 0)和var s []int内存表现一样 —— 其实前者已分配底层数组头结构，后者连头都没有；但对“是否为空”这个问题，它们行为完全一致
真正要小心的，从来不是“怎么写才对”，而是“为什么我写的看起来对，但在泛型、JSON、接口传参这些上下文里突然不对”——核心就一条：len(s) == 0 是唯一跨场景安全的判空方式，其余都是特例里的特例。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
