必须放 []byte，不能放 []byte 值类型；因值类型 Put 会复制切片头且无法统一重置 len，易致数据残留与竞态，而 []byte 可通过指针确保底层数组复用与安全清零。
sync.Pool 里放 *[]byte 还是 []byte？
必须放 *[]byte（指针），不能放 []byte 值类型。Go 的 sync.Pool 存储的是 interface{}，而 []byte 是值类型，每次 Put 都会复制底层数组头（3 字段），但更重要的是：若存值类型，Get() 返回后修改 len 或 cap 不会影响池中原始副本，导致复用失效；更危险的是，多个 goroutine 可能同时拿到相同底层数组的独立切片头，引发竞态写。
正确做法是存 *[]byte，确保所有操作指向同一块底层数组：
var byteSlicePool = sync.Pool{
New: func() interface{} {
b := make([]byte, 0, 1024)
return &b // 注意取地址
},
}
使用时：
b := byteSlicePool.Get().(*[]byte) buf := *b // 解引用得到可 append 的切片 buf = append(buf, 'h', 'e', 'l', 'l', 'o') // ... 使用完后重置并归还 *b = buf[:0] // 关键：只清 len，保留底层数组 byteSlicePool.Put(b)
为什么不能直接 Put make([]byte, 0, N)？
make([]byte, 0, N) 返回的是值类型切片，直接 Put 它等于每次都在池里存一份新拷贝的切片头，底层数组虽复用，但池中对象本身无法被安全重用——因为下次 Get 拿到的仍是新头，且无从控制其 len 初始值（可能是非零）。更严重的是，若你在 New 中写 return make([]byte, 0, 1024)，Get() 返回后你无法通过指针重置它，只能靠 slice = slice[:0]，但这对池中对象无影响。
立即学习“go语言免费学习笔记（深入）”；
- 错误示例：
New: func() interface{} { return make([]byte, 0, 1024) }→ Get 后无法统一重置，不同 goroutine 拿到的len可能不同 - 正确路径：New 返回
*[]byte，Get 后解引用得切片，用完前执行*p = (*p)[:0] - 若结构体字段是
[]byte，Put 前必须显式重置：s.Data = s.Data[:0]，不是s.Data = nil
预分配容量和逃逸分析怎么配合？
即使用了 sync.Pool，如果 make([]byte, 0, N) 中的 N 太大（如 > 32KB），或该切片被赋给全局变量、传入 interface{}（比如 fmt.Println(buf)），仍会逃逸到堆，失去栈分配优势——而 sync.Pool 管理的本来就是堆对象，这反而让 GC 多扫一个“本可避免”的大块。
验证是否逃逸：用 go build -gcflags="-m -l" 编译，确认 New 函数里的 make 是否出现 escapes to heap。若出现，说明预分配本身已触发堆分配，Pool 只是在管理已逃逸对象，收益打折。
- 建议 N 控制在 1KB–8KB 区间，兼顾复用率与单次分配成本
- 避免在
New中做耗时操作（如读文件、调 HTTP），否则拖慢 Get 性能 - 若业务中切片长度波动极大（比如有时 10B，有时 2MB），Pool 效果会急剧下降——大尺寸对象滞留池中，小请求拿不到合适缓冲
Get 后不重置 len 就 panic？
不会立即 panic，但极大概率导致逻辑错误。比如你从池中拿到一个之前存过 "GET /health" 的 []byte，len 是 13，但你没执行 buf = buf[:0]，直接 append(buf, 'P', 'O', 'S', 'T')，结果是 "GET /healthPOST" —— 旧数据残留，HTTP 解析失败、JSON 解析错位、日志内容污染。
这不是 Go 的 bug，是复用契约未履行：
-
Get()不保证返回干净对象，New只兜底，不替代重置 - 必须在业务逻辑开始前完成重置：
buf = buf[:0]或*p = (*p)[:0] - 若切片用于网络 I/O（如
conn.Read(buf)），未重置可能导致读到上一次的尾部字节 - 用
pprof --alloc_space压测时，若发现[][]byte分配量没降，大概率是重置漏了
真正容易被忽略的点：重置动作必须在对象脱离任何外部引用之后、但又要在业务使用之前完成——不是写在 New 里，也不是放在 defer 末尾，而是紧贴业务入口。
