不等价。nil切片底层数组指针为nil，[]t{}指针非nil；前者序列化为null、后者为[]，且s==nil仅对var s []t成立，append对二者均安全但扩容行为不同。
![如何在golang中初始化一个nil切片与空切片_nil vs []t{}](https://img.php.cn/upload/article/000/969/633/177165966396419.jpeg)
nil 切片和 []T{} 真的等价吗？
不等价。它们长度和容量都是 0，但底层指针状态不同：nil 切片的底层数组指针为 nil，而 []T{} 的底层数组指针非 nil（指向一个零长数组）。这会影响序列化、比较、反射行为，也常在 JSON 解析或接口断言时暴露问题。
-
nil切片：未分配底层数组，len(s) == 0且cap(s) == 0，但unsafe.Pointer(&s[0])会 panic -
[]T{}：已分配一个长度为 0 的底层数组，&s[0]合法（但不能解引用），unsafe.Pointer(&s[0])返回有效地址 - JSON 反序列化时，
nil切片字段默认保持nil；而[]T{}字段会被反序列化为长度为 0 的切片（非nil）
什么时候该用 var s []T，什么时候用 s := []T{}？
取决于你是否需要“可追加”和“语义明确性”。var s []T 声明的是 nil 切片，s := []T{} 是非 nil 空切片 —— 两者都可直接传给 append，但初始化开销和内存布局不同。
- 声明字段或函数返回值时，优先用
var s []T（更轻量，无额外内存分配） - 需要与
nil明确区分（比如 API 响应中，“没有数据” vs “空列表”）时，用[]T{} - 测试中判断“是否被赋过值”，
s == nil只对var s []T有效，对[]T{}永远为 false -
make([]T, 0)和[]T{}行为一致，但后者更简洁；make([]T, 0, 0)也是nil切片（注意：这是个常见误解）
nil 切片调用 append 会 panic 吗？
不会。Go 运行时对 nil 切片的 append 有特殊处理：第一次 append 会自动分配底层数组，效果等同于 make([]T, 1, 1)。
-
var s []int; s = append(s, 42)→s变成长度 1、容量 1 的切片，底层数组已分配 - 但
len(s) == 0 && cap(s) == 0时，s[0]或s[:1]会 panic，append是唯一安全的“唤醒”方式 - 如果后续频繁追加，
nil切片首次append的扩容策略可能不如预估容量的make([]T, 0, N)高效
JSON 序列化/反序列化中的典型坑
Go 的 encoding/json 对 nil 和空切片的处理不一致，尤其在结构体字段上容易引发隐性 bug。
立即学习“go语言免费学习笔记（深入）”；
- 序列化时：
nil切片输出null，[]T{}输出[] - 反序列化时：
null→ 字段保持nil；[]→ 字段变为非nil空切片 - 若结构体字段声明为
var Items []string，且上游可能发"items": null，那Items == nil成立；但如果用Items []string = []string{}初始化，就永远无法通过== nil判断是否缺失 - 第三方库（如
mapstructure）有时会把缺失字段设为[]T{}而非nil，导致逻辑分支错乱
len 和 cap，得看它是不是真 nil —— 尤其在跨服务通信、配置解析、单元测试 mock 场景下，这个差异不是理论问题，是立刻会报错的点。 
