sync.Pool 不适合高并发短生命周期场景，易因锁争用和 GC 压力拖慢吞吐；适用对象构造代价高、生命周期与请求对齐且需重置的类型，如 json.Decoder、bytes.Buffer。
Go 中 sync.Pool 用错反而拖慢吞吐量
不是所有对象复用都适合上 sync.Pool，尤其在高并发短生命周期场景下，它可能因内部锁争用和 GC 压力反成瓶颈。
典型误用：把 []byte 或小结构体（如 struct{ ID int; Name string }）无差别塞进池子，但实际分配开销远小于池的 Get/Put 开销 + 内存碎片管理成本。
- 适用场景：对象构造代价高（如
json.Decoder、bytes.Buffer）、生命周期与请求对齐、且单次使用后可安全重置 - 必须重置字段：Put 前清空可变状态，否则下次 Get 可能拿到脏数据（常见于未重置
bytes.Buffer的Reset()） - 避免跨 goroutine 共享：Pool 是 per-P 的，跨 P 调度时 Get 可能触发 slow path，加剧竞争
切片预分配比 append 动态扩容快 2–5 倍
频繁 append 导致底层数组反复 realloc + copy，尤其在已知容量范围时，预分配直接绕过扩容逻辑。
比如解析 HTTP body 中的 JSON 数组，若预估元素数在 10–100 之间，用 make([]Item, 0, 64) 比 make([]Item, 0) 更稳。
立即学习“go语言免费学习笔记（深入）”；
- 用
cap()判断是否需扩容：仅当len(s) == cap(s)时才append，否则直接赋值s[i] = x - 注意：预分配过大（如
make([]byte, 0, 1）会浪费内存，且触发大对象分配走堆而非栈 - HTTP handler 中常见坑：用
strings.Builder拼接响应但没调Grow()，导致内部[]byte多次扩容
runtime.GC() 手动触发基本没用，还容易引发 STW 尖刺
Go 的 GC 是并发、自适应的，手动调 runtime.GC() 不仅无法精准回收，还会强制启动一轮完整 GC，暂停所有 goroutine（哪怕只持续几毫秒），在延迟敏感服务中极易暴露为 P99 毛刺。
真正有效的做法是控制对象生命周期，而不是催 GC。
- 优先用栈分配：小对象、短生命周期变量尽量让编译器逃逸分析判定为栈上分配（可通过
go build -gcflags="-m"确认） - 减少指针深度：嵌套结构体含指针越多，GC 扫描越慢；必要时拆分成 flat struct + 索引数组
- 避免全局 map 存活对象：长期存活的 map 会让 key/value 无法被回收，改用带 TTL 的
sync.Map或定期重建
pprof 抓不到真实瓶颈？检查 net/http/pprof 是否启用了采样偏差
默认 /debug/pprof/profile 是 30 秒 CPU profile，但若服务 QPS 低或请求耗时短，很可能采样不到热点函数；而 /debug/pprof/heap 默认是 mallocs 统计，不是实时堆快照。
- 抓 CPU 真实热点：加
?seconds=60延长采样时间，或用runtime.SetCPUProfileRate(1e6)提高精度（纳秒级） - 看内存泄漏：访问
/debug/pprof/heap?debug=1查 allocs vs inuse，重点盯住 inuse_space 不降反升的类型 - 别只信火焰图顶部：底部窄但高频的调用（如
time.Now()在日志里每行都打）常被忽略，需结合go tool pprof -top看调用频次
线上 profiling 最容易被忽略的是：没关掉开发环境才需要的 log.Printf 和 fmt.Sprintf，它们在高并发下会悄悄吃掉大量 CPU 和内存。
