不等价。nil切片底层数组指针为nil，[]T{}指针非nil；前者序列化为null、后者为[]，且s==nil仅对var s []T成立，append对二者均安全但扩容行为不同。

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)。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 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 场景下，这个差异不是理论问题，是立刻会报错的点。