len 是你能安全读写的元素个数，cap 是从当前 data 指针到底层数组末尾还可容纳的新元素数；cap 不关心前缀是否被截断，仅取决于底层数组总长与起始偏移。
cap 和 len 的本质区别是什么？
不是“容量 vs 长度”这种抽象说法，而是： len 是你**能安全读写的元素个数**，cap 是你**还能往底层数组里塞多少个新元素而不换内存**。
关键在于“从哪开始算”——cap 是从当前切片的 Data 指针位置，一直数到底层数组末尾；它不关心前面有没有被截掉的旧元素。所以：
-
s := arr[2:4]→len(s) == 2，cap(s) == len(arr) - 2（不是len(arr) - 4） - 对
map或chan调用cap会编译报错：invalid argument to cap - 空切片不等于
nil：var s []int和s = []int{}都满足len(s) == 0，但前者cap(s)是 0，后者可能非零
append 触发扩容的条件和实际行为
触发重新分配的唯一条件是：len(s) == cap(s) 且还要再 append 至少一个元素。但扩容后的新 cap 并不固定，不能假设“一定翻倍”。
Go 运行时按当前 cap 分段策略扩容（截至 2026 年仍沿用该逻辑）：
cap ：直接翻倍-
cap >= 1024：每次增加约 12.5%（即乘以 1.125），避免浪费过大内存 - 无论哪种，最终
cap总是 ≥len，且永远是整数
示例：s := make([]int, 0, 1023)，追加第 1024 个元素时 cap 变成 2046；而 s := make([]int, 0, 1024) 后追加，cap 会变成 1152 左右（不是 2048）。
为什么不能靠 cap(s) - len(s) 做“剩余空间”判断？
因为这个差值看似是“还能 append 多少”，但实际无法反映真实可用性——尤其当你反复截取、复用底层数组时。
典型陷阱：
-
s := make([]int, 5, 10); s = s[:3]→len==3,cap==10，cap-len == 7，但底层数组前 5 个位置其实已被初始化过，后续append虽然复用内存，却可能覆盖旧值（若未清零） - 更危险的是：
s = append(s, x)后立刻检查cap(s)，却发现它比预期大得多——这不是 bug，是运行时为后续多次append预留的空间，但你误以为“还能稳插 7 个”
正确做法：预分配就用 make([]T, 0, expectedCap)；不确定时，宁可多一次分配，也别依赖 cap-len 推算边界。
怎么安全地“收缩”切片容量？
Go 不提供直接缩小 cap 的语法，因为底层数组一旦分配，就不会自动释放。但你可以强制切断与原数组的联系：
- 最常用：
s = append([]T(nil), s...)—— 创建新底层数组，cap == len - 如果只是想丢弃头部冗余：
s = s[n:]不改变cap，但s = append([]T(nil), s[n:]...)才真正重置容量 - 注意：
s = s[:0]只清长度，cap不变，底层数组还挂着，GC 不会回收
这点特别容易被忽略：你以为 s = s[:0] 就“释放了”，其实没释放——只要还有变量指向那块内存，它就一直占着。
