sync.Pool 为什么不能直接存指针到结构体？
因为 sync.Pool 不保证对象生命周期，Put 进去的值可能被随时 GC 回收或清空，如果存的是指向堆上结构体的指针，而该结构体本身没被 Pool 管理，就容易出现悬垂指针或重复初始化问题。
常见错误现象：panic: runtime error: invalid memory address 或字段值“随机”变零——其实是拿了已被复用/重置的对象。
- 正确做法：Pool 存的是值类型（如
*MyStruct），且每次Get()后必须检查是否为 nil，是则 new 一个；Put()前清空可变字段（如切片底层数组、map、通道等） - 不要存
**MyStruct或指向外部分配内存的指针 - 如果结构体很大，建议用
unsafe.Pointer+ 自定义内存池，但代价是失去 GC 友好性
如何避免 sync.Pool 中的切片残留数据？
Pool 复用对象时不会自动清空 slice 的 len 和 cap，只保留底层数组。下次 Get() 拿到的 slice 可能带着上次的旧数据，导致逻辑错乱或越界读写。
使用场景：高频创建临时 []byte、[]int 做缓冲区或中间计算。
立即学习“go语言免费学习笔记（深入）”；
- 每次
Get()后，用s = s[:0]重置长度（不是nil，否则下次append可能扩容） - 在
New函数里统一初始化容量，比如make([]byte, 0, 1024) - 如果业务允许，Put 前手动置空关键字段：
v.data = v.data[:0]、v.err = nil
sync.Pool 的 New 函数什么时候会被调用？
只在 Get() 返回 nil 时触发，且每个 goroutine 第一次 Get 才会调用（之后优先从本地 P 的 private slot 拿）。它不是“每 Put 一次就配一个 New”，也不是全局单例初始化。
性能影响：New 函数若做 heavy 初始化（如打开文件、建连接），会拖慢首次 Get，而且无法复用——Pool 本意是规避分配，不是替代构造逻辑。
- New 应该极轻量，只做
&MyStruct{}或make，不带副作用 - 不要在 New 里调用
time.Now()、rand.Intn()等非幂等操作 - 如果需要带上下文的初始化，得在 Get 之后、使用前单独处理，别塞进 New
为什么高并发下 sync.Pool 的命中率突然暴跌？
本质是 Go 运行时对 Pool 的清理策略：每次 GC 后，所有 Pool 的 victim cache 会被清空，且 global 链表只保留最近一次 Put 的对象；同时，goroutine 迁移或 P 被抢占会导致 local pool 遗弃。
兼容性影响：Go 1.13+ 引入 victim 机制缓解，但无法根治；在短生命周期 goroutine（如 HTTP handler）中尤其明显。
- 命中率低不等于失效，只是退化为“偶尔复用”，仍比每次都 new 好
- 别依赖 Pool 100% 避免分配，用
go tool pprof看runtime.mallocgc占比更实在 - 如果发现大量对象没被复用，检查是否 Put 太晚（比如 defer Put 但函数 panic 了）、或 Get 后忘了 Put
Pool 的边界很清晰：它不解决所有权、不保证顺序、不提供同步语义。真正难的从来不是怎么写 New，而是判断某个对象到底“值不值得放进 Pool”。
