sync.pool不支持自适应大小，因其new函数返回固定容量对象，无法按字符串实际长度动态选池；需自行构建多级池+容量路由逻辑，分档映射不同sync.pool实例并确保原路归还。
sync.Pool 本身不支持自适应大小——它只管“拿”和“放”，不管块多大、是否匹配。真要按字符串实际长度动态选池，得自己搭多级池 + 容量路由逻辑。
为什么不能直接用 sync.Pool 做自适应字符串池
sync.Pool 的 New 函数返回固定类型对象，比如 []byte 或 *strings.Builder，但无法根据每次请求的字符串长度（如 128B vs 8KB）自动切换底层缓冲大小。强行用一个池配所有尺寸，要么小缓冲频繁扩容（append 触发底层数组 realloc），要么大缓冲浪费内存（比如只拼 10 字符却分配 4KB）。
如何实现多级字符串缓冲池（按容量分档）
核心是把不同长度范围映射到不同 sync.Pool 实例，再加一层路由函数。常见分档策略：64B、256B、1KB、4KB、16KB —— 覆盖 HTTP header、JSON 小字段、body 片段等典型场景。
- 每个档位独立初始化
sync.Pool，New返回对应容量的[]byte或strings.Builder - 获取时用
bits.Len64(uint64(size))或简单 if-else 找到最接近且 ≥ 请求长度的档位 - 归还时必须原路返回对应池，不能混投；否则小池收到大缓冲会撑爆，大池收小缓冲则浪费
- 如果用
strings.Builder，注意它的Grow可能突破初始容量，Put 前建议调b.Reset()清空状态，避免下次 Get 后Len()非零
strings.Builder 比 []byte 更适合字符串拼接池吗
是，但有条件：
- 拼接为主、极少读取中间态 →
strings.Builder更稳，WriteString零拷贝，String()仅一次底层转换 - 需要频繁切片、随机访问字节 → 用
[]byte，strings.Builder底层虽是[]byte，但没暴露Bytes()以外的直接访问方式（Go 1.22+ 才有UnsafeString()） -
strings.Builder的cap不透明，无法精确控制预分配大小；而[]byte可写死make([]byte, 0, 4096)，更利于内存对齐与复用 - 若业务要求“绝不残留旧内容”，
[]byte必须手动buf = buf[:0]；strings.Builder的Reset()更明确，且内部已处理清零
容易被忽略的归还时机与竞态点
字符串池最难绷住的不是分配，而是归还：
- 别在闭包或 goroutine 中异步 Put ——
sync.Pool是 per-P 缓存，跨 P Put 可能导致对象永远进不了本地缓存，下次 Get 还得走全局路径甚至触发New - HTTP handler 中，如果中间件提前 return（如 auth 失败），记得显式 Put，否则缓冲泄漏
- 用
strings.Builder时，不要在String()后直接 Put：它内部可能保留引用，应先Reset()再 Put - 池中对象若含指针字段（比如自定义结构体嵌套
*bytes.Buffer），Put 前需置空，否则 GC 无法回收被间接引用的内存
New 函数必须极轻量——不能有锁、不能 IO、不能调用 time.Now()。自适应的关键不在“智能”，而在“确定性路由 + 无残留归还”。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
