不能复用字符串本身，但可以复用 bytes.buffer 或预分配的 []byte 来高效拼接字符串——这才是真正降低 gc 压力的路径。因为 string 是只读不可变值类型，无法重置或安全复用，强行池化无效且易引发竞态；而 bytes.buffer 和 []byte 可通过 reset() 或切片截断反复清空复用，且 new 中预分配容量能显著减少逃逸和分配开销。
不能复用字符串本身，但可以复用 bytes.Buffer 或预分配的 []byte 来高效拼接字符串——这才是真正降低 GC 压力的路径。
为什么不能把 string 放进 sync.Pool
Go 的 string 是只读且不可变的底层 []byte 封装，每次拼接（如 + 或 fmt.Sprintf）都会产生新分配。你无法“重置”一个 string，也无法安全复用它——sync.Pool 要求对象可反复清空、复写，而 string 不满足这个前提。强行包装 string 进池，要么无效（每次还得 new），要么引发竞态（多个 goroutine 写同一底层数组）。
-
string本身是值类型，小字符串通常栈分配，不走 GC；大字符串底层[]byte才上堆，但你无法控制其复用逻辑 -
sync.Pool.Put("hello")没意义：字符串字面量常量不会被 GC，而运行时构造的string一旦生成就固定，无法 Reset - 常见误用：试图池化
fmt.Sprintf返回值，结果发现sync.Pool完全没减少 allocs，因为底层分配发生在sprintf内部，你池化的只是个指针封装
正确做法：池化 bytes.Buffer 或 []byte 切片
真正高频、可复用、需预分配的，是拼接过程中的中间载体。选 bytes.Buffer 还是 []byte，取决于使用模式：
- 若以追加为主（如日志行拼接、HTTP body 构建），优先用
bytes.Buffer：它自带增长逻辑，且Reset()清空语义明确 - 若长度可预估（如 JSON 序列化最大 2KB）、且后续要转成
string或[]byte，用make([]byte, 0, N)更轻量，避免Buffer的额外字段和方法调用开销 -
New函数里必须做容量预分配：return &bytes.Buffer{}✅，return make([]byte, 0, 1024)✅；但return make([]byte, 1024)❌（立即写零，浪费 CPU 和带宽）
Get 后不 Reset 就用，等于拿别人吃剩的碗盛饭
从 sync.Pool 取出的对象状态完全不可控——它可能是上次请求留下的完整内容。不清理就直接 WriteString 或 append，结果就是脏数据叠加：
- 对
*bytes.Buffer：必须调用buf.Reset()（不是buf.Truncate(0)，后者不释放底层数组引用，也不清空 cap 外残留） - 对
[]byte：必须重置长度，b = b[:0]；如果结构体里嵌了 slice 字段，也要显式截断，不能只设为nil - 错误示例：
buf := bufPool.Get().(*bytes.Buffer); buf.WriteString("a"); _ = buf.String()—— 下次Get到的buf里可能还带着上次的 "a"，再写 "b" 就变成 "ab" + 新内容
Put 的时机比你想的更严格
sync.Pool.Put 不是“回收通知”，而是“移交所有权”。一旦 Put，该对象随时可能被别的 goroutine 拿走。此时若原 goroutine 还在读写，就是 use-after-free。
- 禁止在
defer里无条件Put：比如 handler 中启动异步 goroutine 并传入buf指针，defer执行时buf可能还在被并发读写 - 安全时机：确认对象已彻底脱离作用域——HTTP response 写完、channel 发送完成、闭包未捕获、无 goroutine 持有其指针
- 特别注意：不要把
*http.Request或*http.ResponseWriter放池里，它们本身由 net/http 复用；你该池化的是它们处理过程中临时创建的缓冲区
真正起效的前提，是你已经通过 go tool pprof 确认 allocs/op 高峰来自 []byte 或 bytes.Buffer 分配，并且单次对象大小控制在几 KB 内。超过 32KB 的缓冲区会绕过 mcache 直接走大对象分配，sync.Pool 基本失效。别在低频路径上硬加 Pool，命中率趋近于 0 时，它只是多一层原子操作开销。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
