清空切片但保留底层数组应使用 s = s[:0]，它将 len 设为 0 而 cap 不变，支持内存复用；而 s = nil 会丢弃底层数组，触发新分配。
清空切片但保留底层数组：用 s = s[:0]
这是最常用也最安全的做法。它把切片长度设为 0，但容量不变，底层数组没被丢弃，后续追加元素时能复用内存，避免频繁分配。
常见错误现象：append 后发现旧数据“残留”——其实是没清空长度，只重置了指针或误用了 nil 赋值。
- 适用场景：循环复用切片（比如解析多条日志、批量处理请求），追求性能且确认旧数据不会造成逻辑污染
- 注意：
s[:0]不改变cap(s)，len(s)变成 0，s[0]会 panic - 和
s = nil的关键区别：后者会让下一次append从头分配数组（除非 cap 很小触发小对象优化）
彻底丢弃底层数组：赋值 s = nil
这会让 Go 的垃圾回收器在无其他引用时回收底层数组。适合一次性大块数据处理后明确不想再用的场景。
常见错误现象：反复 s = nil 后又 append，导致每次分配新底层数组，GC 压力上升、性能下降。
立即学习“go语言免费学习笔记（深入）”；
- 使用前确认：没有其他变量指向同一底层数组（比如通过
s2 := s[1:3]切出来的子切片） - 参数差异：
nil切片的len和cap都是 0，而s[:0]的cap保持原值 - 性能影响：首次
append可能触发内存分配；若原切片很大，提前释放有助于降低内存峰值
make([]T, 0, cap) 和 s[:0] 效果一样吗？
效果相同，都是清空长度、保留容量。但语义和可读性不同：s[:0] 更直接反映“我在复用这个切片”，make 则像新建一个——容易让人误以为底层数组换了。
- 不要写
s = make([]int, 0, len(s))来“清空”，这纯属多此一举，还可能因手误写成cap(s)漏掉，导致容量丢失 - 如果真要新建（比如想强制换底层数组防泄漏），得用
s = append([]int(nil), s...)或显式make+copy，但极少需要 - 兼容性无差异，两者生成的切片行为完全一致
清空后 append 性能差异在哪？
差别就在是否触发扩容。用 s[:0] 后 append(s, x) 只要不超过原 cap 就不分配；s = nil 后第一次 append 至少分配 1 个元素空间，按 Go 的扩容策略（小于 1024 翻倍，之后按 1.25 增长）可能多分不少。
- 典型坑：日志缓冲切片设为
make([]byte, 0, 4096)，每次处理完用s = nil，结果每条日志都触发一次 4KB 分配 - 调试技巧：用
fmt.Printf("len=%d cap=%d\n", len(s), cap(s))快速验证清空是否生效 - 真正要注意的不是“清空动作本身”，而是后续怎么用——别让
s[:0]后忘了检查cap是否足够，否则append还是会扩容
s[:0] 是默认选择，但别把它当成银弹——如果切片曾存过敏感数据（如密码、token），或者你根本不确定后续会不会有子切片引用它，那 s = nil 反而是更稳妥的收尾方式。 
