切片底层数组在未超出原容量时被复用；append 超出 cap 会扩容并复制，导致原引用失效；判断依据是 len(s)+n ≤ cap(s)。
切片底层数组何时被复用？
go 的切片是引用类型，底层共享同一段数组内存。只要没超出原数组容量，新切片就复用底层数组——这是高效的关键，也是隐患的源头。
常见错误现象：append 后原切片内容被意外修改，或函数返回的切片在调用方继续 append 时触发扩容，导致底层数组复制，旧引用失效。
- 判断是否复用：检查
cap(s)是否足够容纳新增元素；若len(s) + n ，则复用；否则分配新底层数组 - 避免意外共享：需隔离数据时，显式拷贝，如
newSlice := append([]T(nil), oldSlice...)或copy(dst, src) - 注意
make([]T, len, cap)中cap设得过大，虽避免频繁扩容，但会占用更多未使用的内存
预估容量能省多少次内存分配？
每次 append 超出 cap 时，运行时按近似 2 倍策略扩容（小 slice 可能是 +1、+2、×2），反复分配、拷贝、释放带来 GC 压力和延迟抖动。
使用场景：批量构建切片（如解析 JSON 数组、读取文件行、聚合 DB 查询结果）。
立即学习“go语言免费学习笔记（深入）”；
- 已知最终长度：直接
make([]T, 0, expectedLen)，后续append全部复用底层数组，仅一次分配 - 长度范围较明确：按上限预估，比如「最多 1000 条日志」，就设
cap=1000，比默认起始cap=0或cap=1少 8–10 次扩容 - 不确定长度但有典型分布：可结合
runtime/debug.ReadGCStats观察PauseTotalNs和分配次数，验证预估效果
为什么 [:0] 清空切片不释放内存？
s = s[:0] 只重置长度为 0，cap 不变，底层数组仍被持有。这在循环复用切片时很高效，但也容易造成内存长期驻留，尤其当原切片曾容纳大量数据。
性能影响：无分配开销，但可能阻碍 GC 回收底层数组（只要该切片变量还存活，且底层数组未被其他引用）。
- 需要真正释放内存时，应改用
s = nil或重新make，让旧底层数组失去所有引用 - 若只是临时清空并立即重填，
s = s[:0]是最优选择；但若之后长时间不用，又没重新赋值，就构成内存泄漏风险 - 注意：函数参数传入切片后在内部做
s = s[:0]，不会影响调用方的底层数组引用，因为切片本身是值传递（含指针、len、cap 三个字段）
字符串转 []byte 的零拷贝陷阱
[]byte(str) 总是分配新底层数组并拷贝内容——它不是零拷贝。虽然 Go 1.22 引入了 unsafe.String 反向操作的优化路径，但正向转换仍无法绕过拷贝。
容易踩的坑：高频将短字符串转 []byte（如 HTTP header 处理、日志字段拼接），成为 CPU 和内存分配热点。
- 只读场景：优先用
string，避免转[]byte；bytes.Equal等函数也支持string参数重载 - 必须可写且需复用：预先分配
[]byte缓冲池（如sync.Pool），避免每次分配；注意池中对象生命周期管理 - 绝对不能用
unsafe.Slice(unsafe.StringData(s), len(s))试图“强制转换”——string数据可能被 GC 移动或复用，导致崩溃或数据错乱
实际优化中，最常被忽略的是对「复用」边界的误判：以为 s[:0] 后就可以放心扔掉旧引用，却没意识到切片变量本身仍在栈/闭包中持有底层数组。内存效率不只看分配次数，更要看引用链是否及时断裂。