17370845950

len 和 cap 的行为因类型而异：slice 中 len 是当前长度、cap 是可扩展空间；array 中二者相等；map/channel 不支持 cap；常见错误是误判 append 后 cap 变化，应结合 len 与 cap 判断扩容能力。

len 和 cap 的行为差异经常被误读

很多人以为 len 就是“元素个数”，cap 就是“底层数组总长度”，但实际要看类型：对 slice，len 是当前有效长度，cap 是从 slice 起始位置到底层数组末尾的可扩展空间；对 array，len 是固定长度，cap 等于 len；对 map 或 channel，len 有效，cap 不支持（编译报错 invalid argument to cap）。

常见错误是扩容后没检查 cap 是否真变大了——比如 s = append(s, x) 后直接假设 cap(s) > len(s)，但若原 slice 已满且底层数组无空闲，append 会分配新数组，此时 cap 可能远大于 len，也可能刚好多 1，不可预测。

• 用 len(s) 判断是否为空：安全，推荐 len(s) == 0 而非 s == nil（空 slice 不等于 nil）
• 用 cap(s) 做预分配判断时，必须结合 len(s)：比如 if cap(s)-len(s) 这类操作极易出错，应改用 make([]int, len(s)+n, cap(s)+n) 显式控制
• 对函数入参是 slice 时，不要依赖调用方传来的 cap 值做性能假设——它可能被截断过（如 s[1:3]），cap 会变小但底层数组未变

append 不是“往末尾加一个”，而是“返回新 slice”

append 永远返回一个新的 slice 值，原变量不变。这是值语义的关键体现，也是最常被忽略的点。写成 append(s, x) 却不赋值给变量，等于什么都没做。

var s []int
append(s, 1) // ❌ 无效果，s 仍是 nil
s = append(s, 1) // ✅ 正确

另一个陷阱是“链式 append”误用：

s := []int{1}
s = append(s, 2)
s = append(s, 3) // ✅ 安全
// 但：
s = append(append(s, 2), 3) // ⚠️ 效率低，中间产生临时 slice，gc 压力大

• 批量追加用 append(s, t...)，不要循环单个 append
• 避免在循环中反复 append 小量数据——先估算总量，用 make([]T, 0, estimatedCap) 预分配
• 注意 append 可能改变底层数组指针：若原 slice 的 len == cap，新增元素必然触发扩容并返回指向新数组的 slice，所有旧引用失效

make 创建 slice 时，len 和 cap 参数含义必须分清

make([]T, len, cap) 中，len 是初始长度（可直接索引 [0..len-1]），cap 是容量上限（cap >= len，否则 panic）。初学者常把第二个参数当成“分配多少内存”，其实它只影响后续 append 是否立即扩容。

s1 := make([]int, 5)        // len=5, cap=5 → 写 s1[5] panic, append 一个就扩容
s2 := make([]int, 5, 10)   // len=5, cap=10 → 可 append 5 个不扩容
s3 := make([]int, 0, 10)   // len=0, cap=10 → 空 slice，但 append 前 10 个都不扩容

• 初始化已知大小的数据，用 make([]T, n) 最简洁
• 准备大量追加，但初始无数据，用 make([]T, 0, n) 避免多次扩容
• 不要写 make([]T, 0, 0)——合法但无意义，等价于 []T(nil)
• cap 超过系统页大小（如几 MB）不会立即分配物理内存，Go runtime 按需映射，所以设很大 cap 并不耗资源，但逻辑上要确保不会意外越界

nil slice 和 zero-length slice 的行为几乎一致，但有 1 个关键区别

两者 len 和 cap 都为 0，都能被 append、遍历、传参，甚至 JSON marshal 都输出 []。唯一实质区别在于：nil slice 的底层指针为 nil，而 zero-length slice（如 make([]int, 0)）指针非 nil，指向一个真实但空的底层数组。

这导致唯一可观测差异：对 nil slice 调用 reflect.ValueOf(s).IsNil() 返回 true，对 make([]int, 0) 返回 false；以及某些底层序列化库（如 cgo 交互）可能校验指针是否为空。

• 判空统一用 len(s) == 0，不要用 s == nil
• 函数返回 slice 时，优先返回 nil（如 return nil），而非 return []T{} 或 return make([]T, 0)，语义更清晰且节省一次 malloc
• 接收方无需区分 nil 和 zero-length，除非你在写 reflect 或 unsafe 相关代码

Golang 内置函数看似简单，但 len/cap 的类型敏感性、append 的不可变返回、make 的双参数语义，三者叠加容易在边界场景翻车——尤其是当 slice 经过多层函数传递、切片截取、并发修改后，底层数组状态早已脱离直觉。别依赖“差不多”，每个 append 都要问自己：这次扩容了吗？指针还一样吗？