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”误用:
立即学习“go语言免费学习笔记(深入)”;
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 相关代码
len/cap 的类型敏感性、append 的不可变返回、make 的双参数语义,三者叠加容易在边界场景翻车——尤其是当 slice 经过多层函数传递、切片截取、并发修改后,底层数组状态早已脱离直觉。别依赖“差不多”,每个 append 都要问自己:这次扩容了吗?指针还一样吗?










