slice = slice[:0]是最安全的清空方式，仅将长度置0而保留底层数组和容量，适用于缓冲池等复用场景；误用nil或空切片字面量会导致底层数组被回收。
用 slice = slice[:0] 清空但不释放内存
这是最直接、最常用的方式。它把切片长度设为 0，但底层数组引用不变，容量保持原样，后续 append 可以复用原有空间。
常见错误是误用 slice = nil 或 slice = []T{} —— 这俩都会让原底层数组失去引用，可能触发 GC 回收，违背“不释放内存”的初衷。
-
slice = slice[:0]：安全，保留底层数组，适合循环复用场景（如缓冲池、批量处理） -
slice = nil：长度和容量都归零，且原数组若无其他引用会被回收 -
slice = make([]T, 0, cap(slice))效果等价于[:0]，但多一次函数调用，没必要
为什么 slice = slice[:0] 不等于重新分配
Go 切片本质是三元组：ptr（指向底层数组）、len（当前长度）、cap（容量）。[:0] 只改 len，ptr 和 cap 完全不变。
典型使用场景：网络包解析时反复读取固定大小缓冲区，或日志批量收集器中清空待发送队列。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 执行前后
cap(slice)不变，可验证：fmt.Printf("cap: %d", cap(slice)) - 如果后续
append超出原cap，才会触发新底层数组分配 —— 这是 Go 的正常扩容行为，与清空操作无关 - 注意：如果原切片是从大数组或另一个切片截取而来（比如
big[100:200]），[:0]后仍持有整个底层数组引用，可能造成内存泄露（见下一点）
小心隐式持有底层数组导致的内存泄漏
这是最容易被忽略的坑。当你从一个大数组截取小切片再反复 [:0]，GC 无法回收那个大数组，因为小切片的 ptr 仍指向它起始位置。
例如：buf := make([]byte, 1024*1024); slice := buf[512:512+16]; slice = slice[:0] —— 此时 buf 整个 1MB 仍被持有。
- 解决方法：需要真正“切断”底层数组关联时，用
slice = append([]T(nil), slice...)（会分配新底层数组） - 或者更明确地重建：
slice = make([]T, 0, desiredCap)，再手动控制容量 - 调试技巧：用
unsafe.Sizeof(slice)看结构体大小（恒为 24 字节），不能反映底层数组占用；需结合 pprof 分析实际堆内存
在结构体字段中重置切片要留意零值语义
如果切片是结构体成员，直接赋值 s.field = s.field[:0] 没问题；但若想“重置为初始状态”，要注意结构体字面量中的切片字段默认是 nil，不是空切片。
比如：type Req struct { Data []byte }，新建 req := Req{} 后，req.Data 是 nil，此时 req.Data[:0] 会 panic：panic: runtime error: slice of nil pointer。
- 安全写法：先判空，
if req.Data != nil { req.Data = req.Data[:0] } - 或统一初始化为长度 0 的切片：
req := Req{Data: make([]byte, 0, 128)}，后续可直接[:0] - 避免依赖
nil切片的“空”行为，Go 中len(nilSlice) == 0成立，但nilSlice[:0]不合法
真正麻烦的从来不是怎么写那行代码，而是得时刻记得：切片不是值，它背后拖着一个可能很沉的数组。
