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) 会暴露差异。
