17370845950

Go中slice声明需用[]int而非[3]int，常见方式有var s []int（nil）、[]int{1,2,3}（字面量）、make([]int,3)或make([]int,3,10)；append可能分配新底层数组，须接收返回值；s[i:j:k]中k限定容量为k-i；nil slice与空slice在JSON编码等场景行为不同。

如何声明和初始化 slice（不是 array）

Go 中 slice 是引用类型，底层指向一个数组，但本身不包含数据。声明时不能用 [3]int 这种数组语法，否则得到的是数组而非 slice。

常见错误：写成 var s [3]int —— 这是长度为 3 的数组，不是 slice，无法动态扩容。

• var s []int：声明 nil slice，len(s) 和 cap(s) 都为 0，底层指针为 nil
• s := []int{1, 2, 3}：字面量初始化，自动推导长度和容量
• s := make([]int, 3)：创建长度为 3、容量为 3 的 slice（底层数组已分配）
• s := make([]int, 3, 10)：长度 3、容量 10，预留空间避免频繁 realloc

append 之后为什么原 slice 可能“失效”

append 不总是就地修改：当底层数组容量不足时，append 会分配新数组、拷贝元素、返回新 slice。此时原变量仍指向旧底层数组，内容未变，但新 slice 已脱离它。

典型陷阱：传入函数后只对形参 append，却不返回新 slice，调用方看不到变化。

立即学习“go语言免费学习笔记（深入）”；

func badAppend(s []int) {
    s = append(s, 99) // 这里 s 可能已指向新底层数组
}
func goodAppend(s []int) []int {
    return append(s, 99) // 必须返回，并由调用方重新赋值
}

• 永远假设 append 返回的是新 slice，需显式接收
• 检查容量是否足够：if len(s) == cap(s) { ... } 可预判是否要扩容
• 避免对同一底层数组的多个 slice 同时 append，可能引发意外覆盖（因共享底层数组）

切片操作 s[i:j:k] 中三个参数的实际含义

切片表达式 s[i:j:k] 控制新 slice 的长度与容量，容易混淆的是 k —— 它不是“结束索引”，而是新 slice 的最大可用容量上限（即底层数组从 i 开始到索引 k 的长度）。

• s[i:j] 等价于 s[i:j:len(s)]，新容量 = len(s) - i
• s[i:j:k] 新长度 = j - i，新容量 = k - i（必须满足 i ≤ j ≤ k ≤ len(s)）
• 用 k 可主动限制后续 append 的增长上限，防止意外写入超出预期范围的底层数组区域

s := []int{0, 1, 2, 3, 4, 5}
t := s[2:4:4] // t = [2 3], len=2, cap=2（因为 4-2=2）
u := s[2:4:6] // u = [2 3], len=2, cap=4（因为 6-2=4），append 最多加 2 个元素不扩容

nil slice 和空 slice 的区别与使用场景

nil slice（如 var s []int）和 empty slice（如 s := []int{} 或 make([]int, 0)）在行为上几乎一致：都可直接 append、len/cap 均为 0、可遍历零次。但底层指针不同，影响 JSON 编码和某些反射判断。

• JSON 编码：nil slice 编码为 null，空 slice 编码为 []
• 与 nil 比较：s == nil 只对真正 nil slice 为 true；空 slice 不等于 nil
• 推荐初始化用 var s []T（即 nil），更符合 Go 的零值习惯；除非明确需要非-nil 行为（如传递给要求非-nil 的 API）

多数业务逻辑里二者可互换，但序列化、API 契约或调试时观察 fmt.Printf("%p", &s) 会暴露差异。