预分配容量比append更快，但需合理预估；string转[]byte可浅拷贝但须确保安全场景；sync.Pool需分级管理避免污染；切片截取共享底层数组是特性而非bug，关键在所有权控制。
预分配容量比用 append 更快，但别乱设 cap
如果能预估最终长度，make([]T, 0, estimatedCap) 是最省事的起点。它只分配一次底层数组，后续 append 不触发扩容，避免 O(n) 复制开销。
容易踩的坑是“过度预估”：比如处理 HTTP body 时硬写 make([]byte, 0, 10*1024*1024)，哪怕实际只读 2KB，也白白占住 10MB 内存，还可能被 GC 长期盯上。更稳妥的做法是结合常见请求大小分级——例如小包（100KB）各配一个池或阈值。
- 小数据（make([]byte, len(s))，开销可忽略
- 中等数据（128B–1MB）：用
sync.Pool管理固定尺寸缓冲区（如 4KB、32KB） - 超大数据（>1MB）：考虑流式处理或 mmap，别全 load 到内存
string 转 []byte 必须深拷贝？看场景
[]byte(s) 是浅拷贝，复用 string 底层数组指针。只要后续不修改该切片，且 string 生命周期 ≥ 切片使用期，它就是安全且零分配的。但一旦涉及写操作、并发传递、或 string 来自 unsafe.String 或 mmap 区域，就必须深拷贝。
标准写法是：dst := make([]byte, len(s)); copy(dst, s)。它明确分离内存，无隐式共享风险，编译器对 copy 有内联优化，性能接近 memcpy。
立即学习“go语言免费学习笔记（深入）”；
- 别写
append([]byte(nil), s...)：每次都会新分配底层数组，小字符串浪费空间，大字符串可能多次扩容 - 别写
make([]byte, 0, len(s)); append(dst, []byte(s))：先构造一次浅拷贝，再复制，多一次指针解引用 - 如果后续要
append，用make([]byte, 0, len(s))预设容量，再append(dst, s...)
sync.Pool 复用切片时，大小不匹配会污染池
sync.Pool 本身不区分大小，往里放一个 64KB 的 []byte，下次取出来可能被误用于只需要 1KB 的场景——既浪费内存，又拖慢 GC 扫描。这不是 bug，是设计使然。
真实项目里得自己做分级：按常见尺寸建多个池（如 smallBufPool、mediumBufPool），或者用 size-aware wrapper 封装 Get/ Put 逻辑，取之前检查 cap 是否满足需求，不满足就丢弃重 alloc。
- 不要把不同用途的切片混进同一个池（比如解析协议头的 128B 缓冲和日志行的 4KB 缓冲）
-
Put前记得s = s[:0]清空长度，否则下次Get可能拿到残留数据 - 池中对象生命周期不可控，别存任何带指针或需 finalizer 的结构体
切片截取共享底层数组，不是 bug 是特性
s1 := arr[1:3] 和 s2 := arr[2:4] 共享同一底层数组，改 s1[1] 就会影响 s2[0]。这在多数场景是隐患，但在某些高性能路径下反而是优势——比如解析 TCP 流时，用一个大 buffer 多次 buf[i:j] 截取帧，避免反复分配。
关键在于控制所有权边界：只要所有截取切片都在同一 goroutine 内、生命周期明确、无并发写入，共享就没问题。一旦跨 goroutine 或需独立修改，就得立刻深拷贝。
- 别依赖
copy后的切片还跟原数组有关联——copy生成的是全新底层数组 -
s = s[:len(s):len(s)]可以“切断”容量泄露，防止意外追加污染原数组 - 用
reflect.ValueOf(s).Pointer()可调试验证两个切片是否共享底层数组
