go无法安全复用string，因其不可变且底层字节数组需独立分配；应复用[]byte或strings.builder等可写缓冲区，避免直接缓存string或误用&v导致逃逸。
Go 没有内置的“字符串池”（string 是不可变值类型，且底层数据可能共享，无法安全复用），直接想用 sync.Pool 缓存 string 不仅无效，还会引发严重问题。
为什么不能把 string 放进 sync.Pool
string 本身是只读的头结构（含指针 + 长度），其底层字节数组通常来自堆分配（如 fmt.Sprintf、strconv.Itoa 等结果）。但 sync.Pool 的 Put 和 Get 接口参数是 interface{}，任何值传入都会触发逃逸；更关键的是：string 一旦创建就不可修改，缓存它毫无意义——你无法重置内容，也无法避免重复分配。
- 试图
pool.Put("hello")：字符串字面量常量不分配，但运行时生成的string值传入interface{}后，其底层数组仍留在堆上，Pool 只缓存了那个不可变头，无复用价值 - 若缓存的是
*string或含string字段的结构体，反而增加指针追踪和 GC 压力 - 常见误操作：
pool.Put(str)→str逃逸；后续Get()返回的仍是旧字符串，无法用于新内容拼接
真正该池化的对象：[]byte 和 strings.Builder
高频字符串拼接或序列化场景中，真正产生堆分配的是底层字节数组。替代方案是复用可写的缓冲区：
-
[]byte：适合需要反复写入、清空、重用的场景（如 HTTP body 构造、JSON 序列化中间缓冲） -
strings.Builder：内部持有一个可扩容的[]byte，Reset()后可安全复用，比直接操作切片更语义清晰
示例：
<pre class="brush:php;toolbar:false;">var bufPool = sync.Pool{
New: func() interface{} {
return new(strings.Builder)
},
}
func formatUser(id int, name string) string {
b := bufPool.Get().(*strings.Builder)
b.Reset()
b.Grow(64) // 预分配避免多次扩容
b.WriteString("user:")
b.WriteString(strconv.Itoa(id))
b.WriteByte(':')
b.WriteString(name)
s := b.String() // 此处分配新 string，但底层数组来自池
bufPool.Put(b)
return s
}
range 循环里取 &v 导致 []byte 逃逸的坑
这个错误非常隐蔽，且与字符串生成强相关：
- 写法：
for _, v := range data { _ = &v } → 即使 <code>v是[]byte元素，&v也会让整个循环变量逃逸到堆 - 后果：每次迭代都新建一个堆上
[]byte备份，GC 压力陡增 - 修复：改用索引访问：
for i := range data { _ = &data[i] }，或直接用值（如果不需要地址） - 验证方式：
go build -gcflags="-m -m -l" file.go 2>&1 | grep "escape"，关注&v是否出现escapes to heap
strings.Builder.String() 的逃逸行为要单独看
Builder.String() 返回的 string 必然逃逸——因为它的底层数据来自 Builder 内部的堆分配数组，而 string 类型本身必须持有该数组的只读视图。但这不是问题，而是设计使然：
- 逃逸的是返回的
string值，不是Builder本身；只要Builder被池化，底层数组就复用了 - 不要试图池化
string结果，那是徒劳的；重点是减少Builder底层数组的分配次数 - 如果返回的
string立即转成[]byte（如写入 io.Writer），可考虑直接用Builder.Bytes()避免一次拷贝
真正容易被忽略的点在于：你以为在优化字符串，实际要盯住的是字节数组的生命周期；所有“字符串池”的提法，本质都是对可变缓冲区的复用，而非对 string 本身的管理。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
