bytes.buffer.write比字符串+=快，因其直接向底层[]byte追加，避免每次创建新字符串及全量复制；而+=呈o(n²)时间复杂度，大数据量下性能差距达数量级。
bytes.Buffer.Write 为什么比字符串 += 快
因为 bytes.Buffer.Write 直接往底层 []byte 追加，不创建新对象；而 += 每次都生成新字符串，旧内容全量复制——数据量越大，性能差距越明显，不是几倍，是数量级差异。
常见错误现象：pprof 显示大量 runtime.mallocgc 或 memmove 调用，buffer += ... 循环里 CPU 和内存双飙升。
-
Write([]byte)是零拷贝写入：只要底层数组有空余容量，就直接 append；没空余才触发grow - 字符串拼接的
+=没有“追加”概念，每次都是new(len(old)+len(new))+copy(old)+copy(new) - 即使只写入几百字节，几千次循环后，
+=的总分配量可能达 GB 级（平方级增长）
Write 调用触发扩容的真实条件
bytes.Buffer.Write 是否扩容，取决于当前 len(buf) 加上待写入长度是否超过 cap(buf)，而不是 len(buf) 本身大小。扩容不是按固定步长，而是动态策略：
- 若剩余容量足够：
buf.buf = buf.buf[:len(buf)+n]，仅调整切片长度，无分配 - 若剩余不够但
len(buf) + n ：复用底层数组，<code>copy未读部分到开头，重置off - 否则：分配新数组，容量为
2*cap(buf) + n，再copy未读数据
注意：off 字段影响有效数据范围——Read 后不 Reset 或 Truncate，会导致后续 Write 实际可用容量变小。
WriteString 和 Write 的性能差异在哪
WriteString 内部会把字符串转成 []byte 再调 Write，多一次 unsafe.StringHeader 构造；而 Write 直接操作字节切片，更轻量。但真正影响性能的是后续 String() 调用：
-
bytes.Buffer.String()每次都做 UTF-8 验证，哪怕全是 ASCII 也绕不开 - 如果最终只需输出到
io.Writer（如 HTTP response、文件），直接传&buf，完全不用String() - 如果必须转 string 且纯 ASCII/已知合法，考虑用
strings.Builder替代——它String()是真正的零拷贝
别为了少写一个 []byte(...) 就用 WriteString，尤其在高频循环中；但也不必强求全换 Write，语义清晰更重要。
预分配容量能省多少次 grow
不预分配时，bytes.Buffer 初始容量为 0，第一次 Write 分配 64 字节；之后按需翻倍扩容。处理 1MB 数据，可能触发 10+ 次 grow，每次含分配 + copy。
预分配的关键是估算「最终总字节数」，而非单次写入大小：
- 用
bytes.NewBuffer(make([]byte, 0, estimatedTotalSize))初始化 - 或创建后立刻调
buf.Grow(estimatedTotalSize)（推荐，语义更明确） - 估算偏差 20% 以内基本不会扩容；偏差过大，最多额外 1–2 次 grow，仍远优于默认策略
容易被忽略的是：预分配不能解决 Read 后残留 off > 0 导致的容量误判——Grow 基于 cap(buf.buf) - len(buf.buf)，而 len(buf.buf) 是 len(buf.buf) - buf.off，off 不归零，可用空间就被低估了。
