cap会突然变小是因为其定义为“从切片起始指针到底层数组末尾的元素个数”，截取操作（如s[5:10]）移动起始指针，导致剩余可用空间减少，而非简单减去偏移量；append扩容按分段策略：cap<1024时翻倍，≥1024时约增25%，且扩容后指向新数组，旧数组若被其他切片引用则无法GC，易致内存泄漏。
Go 切片的 len 和 cap 不是静态属性，它们在每次切片操作后都可能变化——但变化方式不总符合直觉，尤其在 append、[:] 截取、函数传参等场景下，容易引发内存泄漏或数据错乱。
为什么 cap 会突然变小？
切片容量由底层数组剩余可用空间决定，不是“固定增长值”。当你从一个大切片中截取小片段时，cap 可能大幅缩水：
-
s := make([]int, 0, 1000)→len=0,cap=1000 -
t := s[5:10]→len=5,cap=995（从索引 5 到底层数组末尾） -
u := t[:2]→len=2,cap=5（t的容量被继承，不是原始 1000）
关键点：截取操作只影响 len 和起始指针，cap 是“从新起始位置到底层数组尾”的长度，不是原切片的 cap 减去偏移量。误以为 cap 还剩 995 就继续 append，结果很快触发扩容——而你本可以复用那 1000 空间。
append 后 cap 怎么跳变？
Go 的 append 扩容策略不是线性，而是分段指数增长：
立即学习“go语言免费学习笔记（深入）”；
- 当前
cap < 1024：新cap= 原cap * 2 - 当前
cap >= 1024：新cap≈ 原cap * 1.25 - 扩容后新切片指向全新底层数组，旧数组若无其他引用会被 GC
陷阱在于：如果某个大切片被多个子切片长期持有（比如日志缓冲区拆分成多段），哪怕只对其中一个调用 append 导致扩容，其他子切片仍指向旧数组——但旧数组无法释放，因为至少有一个子切片还引用着它。这不是 bug，是设计使然，但极易造成隐式内存泄漏。
函数参数传切片时，len/cap 被谁改？
切片本身是值类型（三个字段：指针、len、cap），传参时复制的是这三个字段，不是底层数组。但问题出在“修改”行为：
- 修改元素（
s[i] = x）→ 影响原底层数组，所有共享该数组的切片都可见 - 调用
append(s, x)并赋值给形参变量（s = append(s, x)）→ 仅改变函数内局部变量的指针/len/cap，不影响调用方 - 但如果函数内做了
s = s[:n]或s = append(s, ...)后又通过指针/返回值暴露出去，就可能意外延长底层数组生命周期
典型坑：过滤函数返回 bigSlice[:0]，看似清空，实则保留了原 cap，后续 append 仍复用大数组；正确做法是 make([]T, 0, estimatedSize) 新建切片，切断与原底层数组的联系。
预分配容量时，len 和 cap 该设多少？
多数性能问题源于“只设 cap，忽略 len”：
-
make([]int, 0, 1000)：推荐。长度为 0，容量 1000，append直接写入，无拷贝 -
make([]int, 1000)：长度和容量都是 1000，但前 1000 个位置已被零值占满，append会从第 1001 位开始，且扩容逻辑按cap=1000计算（翻倍到 2000） -
make([]int, 500, 1000)：长度 500，容量 1000，适合已知初始有 500 元素、后续追加不超过 500 的场景
最易被忽略的细节：len 决定当前可读/可写范围，cap 决定还能追加多少而不扩容。两者必须按实际使用节奏匹配，否则要么浪费空间，要么频繁扩容。
