不安全，因strings.Builder的Reset()不清空底层数组容量，Put后可能残留高cap slice导致内存泄漏；应改用bytes.Buffer或自行封装cap截断逻辑。
sync.Pool 里存 *strings.Builder 安不安全？
不安全，除非你手动清空内部 buffer 并重置状态。因为 strings.Builder 底层用的是 []byte，而它的 Reset() 方法只清空内容、不释放底层数组——但关键在于：它没暴露底层 slice 的 cap 控制逻辑，也没提供类似 bytes.Buffer.Reset() 那样明确的复位语义保证。实测发现，若直接 Put 一个写过 1MB 数据的 strings.Builder，下次 Get 出来可能仍持有旧的高 cap slice，导致内存“虚胖”，GC 无法回收底层数组。
真正安全的做法是不用 strings.Builder，改用 bytes.Buffer ——它的 Reset() 明确清空内容且允许复用底层 slice；或者自己封装带 cap 截断逻辑的 builder。
-
strings.Builder没有公开的 reset-cap 机制，不可靠 - 其
Grow()和WriteString()可能悄悄扩大底层数组，Put 前不清空会泄漏内存 - Go 标准库中所有被推荐进
sync.Pool的类型（如bytes.Buffer）都自带可预测的 Reset 行为
为什么 bytes.Buffer 是更稳妥的选择？
因为它在设计上就为池化而生：Reset() 不仅清空 .buf 内容，还确保后续写入不会意外复用旧数据；更重要的是，它的底层数组在多次 Put/Get 后能自然收敛到常用大小，不会无限膨胀。
实操时必须在每次 Get 后立刻调用 Reset()，否则可能残留上一次写入的内容，造成数据污染。
立即学习“go语言免费学习笔记（深入）”；
- 声明池时指定
New：返回新*bytes.Buffer -
Get()后第一行必须是buf.Reset()，不能省略 -
Put()前无需额外清理，Reset()已足够 - 避免在
Put前对buf.Bytes()做长期引用——这会让底层数组无法被复用
大字符串构建场景下，Pool 的 size 控制与 GC 交互怎么影响性能？
sync.Pool 本身不设容量上限，对象存活期只到下一次 GC。这意味着：如果某次请求生成了 2MB 的 buffer，它会被缓存，但若后续请求普遍只需要 4KB，这个 2MB 缓存就成“钉子户”——直到 GC 清理，期间它占着内存却几乎不用。
更麻烦的是，Go 1.22+ 中 GC 触发频率受堆增长速率影响，大 buffer 残留会抬高堆增长率，间接拉高 GC 频率。
- 不要依赖 Pool 自动“瘦身”，需主动控制单次构建最大长度（例如用
buf.Grow(64 * 1024)预分配） - 对超大字符串（>1MB），建议绕过 Pool，直接
make([]byte, 0, size)分配，避免污染池 - 可通过
runtime.ReadMemStats监控HeapObjects和HeapAlloc，验证池是否真在减负
Put 之前忘记 Reset 会出什么问题？
不是 panic，而是静默的数据污染。比如你用同一个 bytes.Buffer 构建两个 JSON 片段：
buf := bufPool.Get().(*bytes.Buffer)
buf.Reset()
buf.WriteString(`{"id":1}`)
// ... 处理逻辑
bufPool.Put(buf) // 忘了 Reset！
<p>// 下次 Get
buf = bufPool.Get().(*bytes.Buffer)
// buf.buf 现在还是 <code>{"id":1}</code>，没清空！
buf.WriteString(<code>,"name":"alice"</code>) // 结果变成 <code>{"id":1},"name":"alice"</code> ——非法 JSON这种 bug 很难复现，只在高并发 + 对象复用率高时偶然触发，日志里看不到错误，只有下游解析失败。
- Reset 必须在 Get 后立即执行，写在 defer 里容易漏（defer 在函数 return 后才跑）
- 绝不能把
buf.String()返回值长期持有，那会阻止底层数组被复用 - 压测时开启
GODEBUG=gctrace=1，观察 GC 次数和 heap 增长是否随 QPS 线性上升——若是，说明 Pool 没起作用或被污染
真正难的从来不是写几行 Get 和 Put，而是确认那个对象内部有没有隐藏状态、Reset 是否真的抹干净、以及它在 GC 周期内会不会悄悄拖垮内存。这些没法靠编译器检查，得靠读源码、看 pprof、跑真实流量。
