strings.Builder写入后内容为空是因为未调用String()方法；必须显式调用builder.String()获取字符串，其返回新字符串且不修改原builder，复用前需Reset()。
strings.Builder 写入后内容为空？检查是否调用了 String()
直接打印 strings.Builder 变量或用 fmt.Printf("%v", b) 看不到内容，是因为它内部是封装的 []byte，不提供自动字符串转换。必须显式调用 String() 才能拿到结果。
- 错误写法：
fmt.Println(builder)→ 输出类似{[...] 0 0}，不是你拼的字符串 - 正确写法：
fmt.Println(builder.String()) - 注意：
String()返回新字符串，不修改 builder 本身；builder 可继续写入 - 如果之后还要复用 builder，记得先调用
Reset()，否则会追加到旧内容后面
为什么不用 += 拼接字符串而要用 strings.Builder？
Go 字符串不可变，每次 s += "x" 都会分配新底层数组、拷贝旧内容，N 次拼接就是 O(N²) 时间复杂度。而 strings.Builder 底层用可增长的 []byte，写入是 O(1) 均摊，适合循环拼接、模板生成等场景。
- 适用场景：HTTP 响应体组装、SQL 拼接、日志格式化、HTML 片段生成
- 不适用场景：只拼 2–3 次静态字符串（
"a" + "b" + "c"编译期就优化好了） - 性能差异明显：1000 次拼接，
Builder比+=快 5–10 倍，内存分配少 90%+
Grow() 要不要提前调用？什么情况下有用
Grow(n) 是预分配至少 n 字节容量，避免后续写入时频繁扩容。但它不改变当前长度，也不清空已有内容，只是“预留空间”。
- 建议用在明确知道最终大小的场景，比如拼接固定结构的日志：
b.Grow(128) - 如果预估过大，浪费内存；预估过小，该扩容还是得扩容，没收益
- 完全不确定长度时，不用调
Grow()也没问题，builder 默认从 0 开始，按需翻倍扩容（类似 slice） - 注意：
Grow()不是线程安全的，多 goroutine 写同一个 builder 必须加锁
builder.Reset() 和重新声明变量，哪个更省？
重复使用同一个 strings.Builder 实例时，Reset() 比 builder = strings.Builder{} 更轻量——它只重置长度为 0，保留已分配的底层数组，下次写入可直接复用内存。
立即学习“go语言免费学习笔记（深入）”；
- 高频复用（如 HTTP handler 中）：用
Reset()，避免反复 malloc/free - 低频或生命周期短：直接声明新变量也无妨，代码更直白
- 一个容易被忽略的点：
Reset()不释放内存，如果 builder 曾经写入巨量内容（比如 10MB），然后长期闲置，这块内存不会自动归还给 runtime；此时需要手动builder = strings.Builder{}或结合make([]byte, 0, 0)强制丢弃底层数组
