Go bufio.Writer 怎么利用 AvailableBuffer 减少临时分配

在循环里把数字、分隔符和短文本拼成一行时，常见写法是先创建临时 []byte，再交给 bufio.Writer。如果这段代码处在日志、导出或协议编码的热路径，临时切片会让分配次数跟着记录数增长。Go 的 bufio.Writer.AvailableBuffer 可以把 Writer 尚未使用的空间借出来：先用 append 或 strconv.AppendInt 填充，再立即调用 Write。

核心用法是 b := w.AvailableBuffer()、b = append(b, ...)、_, err := w.Write(b)。返回切片的长度为 0，容量等于当前可用空间；它只适合在下一次 Writer 写入前使用，最后仍要调用 Flush。

AvailableBuffer 的关键关系：空切片也能减少临时对象

AvailableBuffer 的返回值是一个长度为 0 的字节切片，但它带有 Writer 剩余空间对应的容量。也就是说，len(b) 通常是 0，cap(b) 可能是几千字节；append 会从这个容量开始写，而不是先创建一个与当前记录等长的新切片。

官方文档还给出一个重要边界：这个切片只保证在对同一个 Writer 执行下一次写操作之前有效。因此它的正确生命周期非常短，应该在同一个循环体内完成“取得—追加—写入”。

用 strconv.AppendInt 直接构造一条记录

数字转文本时，strconv.AppendInt 比先转成字符串再拼接更贴合这个 API 的使用方式。下面的例子把序号和换行写入内存中的 bytes.Buffer，真实文件或网络连接只需要替换底层 Writer。

package main

import (
	"bufio"
	"bytes"
	"fmt"
	"strconv"
)

func main() {
	var dst bytes.Buffer
	w := bufio.NewWriterSize(&dst, 64)

	for i := int64(1); i 

这里的 append(line, "item="...) 使用了 Go 对字符串的字节展开语法，最终输出仍是普通 UTF-8 字节。若要写入固定前缀，也可以先用 append(line, "item="...)，再追加数字；不要在循环中先调用 fmt.Sprintf 生成完整字符串后才写入。

容量不足时仍会扩容，不能把它当成零分配承诺

AvailableBuffer 只是提供一个容量起点，并不限制记录长度。如果当前 Writer 剩余空间只有 8 字节，而本轮追加了几十字节，append 会按 Go 切片规则分配更大的底层数组。这样写法依然正确，但“减少临时分配”的收益会变小。

另外，AvailableBuffer 返回的是 Writer 内部写入路径的临时视图。下面这种做法是不安全的：先保存多个返回切片，等循环结束再批量写入。第一次 Write 后，之前的视图就不再满足文档保证。

Flush 后再用基准确认优化是否成立

这类优化应当用目标数据形态验证，而不是只看代码更短。可以准备一组固定数量的短记录，分别比较 fmt.Fprintf、预分配独立切片和 AvailableBuffer 版本，重点观察 allocs/op、吞吐量和峰值内存。底层 Writer 也要保持一致，否则 I/O 差异会盖过切片分配差异。

兼容性上，官方文档将该方法标为 Go 1.18 加入。项目若需要支持更早版本，应继续使用已有的 WriteString、复用工作缓冲或升级最低 Go 版本，不能只在源码里调用后再期待旧编译器兼容。

常见问题

AvailableBuffer 返回的切片为什么 len 是 0？

它是给 append 准备的空切片，容量才表示 Writer 当前可用空间。直接读取或按长度遍历不会得到预留数据。

append 后一定不会分配吗？

不一定。追加内容超过当前容量时仍会扩容；想确认收益，应使用与生产记录接近的基准数据。

Write 后还能继续使用旧切片吗？

不要继续依赖它。官方契约只保证到 Writer 的下一次写操作之前有效，正确方式是每次写入前重新取得。