Go strconv.AppendBool 怎样低分配地追加布尔值

在 Go 里拼接日志行、协议字段或配置文本时，如果布尔值最终要进入已有的 []byte，直接使用 strconv.AppendBool 更顺手：它把 true 或 false 追加到目标切片，并返回可能扩容后的切片。关键点只有一个——一定要接住返回值。

官方文档：https://pkg.go.dev/strconv#AppendBool

我会用一个很小的“配置行构建器”说明这件事。它不追求把所有字符串都变成字节操作，而是把布尔字段放在最适合追加的路径上，再明确什么时候应该回到 FormatBool。

先把布尔字段追加到一行文本

AppendBool(dst, value) 不返回字符串，而是返回追加后的字节切片。下面的函数把字段名、等号和值写入同一块缓冲区，调用方可以继续追加换行或下一个字段。

package main

import (
	"fmt"
	"strconv"
)

// appendFlag 把一个布尔配置字段追加成 name=true 的文本行。
func appendFlag(dst []byte, name string, value bool) []byte {
	// 先写入字段名和分隔符，保持所有内容在同一个字节缓冲区里。
	dst = append(dst, name...)
	dst = append(dst, '=')
	// 必须接住返回值，因为容量不足时 AppendBool 可能返回新的切片头。
	dst = strconv.AppendBool(dst, value)
	return append(dst, '\n')
}

func main() {
	// 预留容量只是一种常见优化，容量不足时仍要依赖返回值继续工作。
	buf := make([]byte, 0, 64)
	buf = appendFlag(buf, "debug", true)
	buf = appendFlag(buf, "cache", false)
	fmt.Print(string(buf))
}

这段代码的输出形态是两行普通文本。真正重要的是赋值链：append、AppendBool 和最后一次 append 都可能改变切片头，后续操作只使用最新返回值。

为什么不能忽略 AppendBool 的返回值

切片包含指针、长度和容量。目标容量足够时，追加可能沿用原底层数组；容量不足时，运行时会分配更大的数组并返回新的切片描述。即使布尔值本身只有几个字符，也不能假设旧变量会自动获得新长度或新底层数组。

package main

import "strconv"

// appendStatus 展示追加后必须继续使用返回的切片。
func appendStatus(dst []byte, ready bool) []byte {
	// 这一行可能触发扩容；忽略返回值会丢失新的长度信息。
	dst = strconv.AppendBool(dst, ready)
	// 返回同一个最新切片，调用方才能继续追加分隔符或其他字段。
	return append(dst, ';')
}

因此，正确的习惯不是只在“可能扩容”时赋值，而是每次都写成 dst = strconv.AppendBool(dst, value)。这样代码对初始容量的变化不敏感，也更容易在后面加入整数、浮点数等同类 Append* 调用。

把缓冲区复用放进循环，但先划清所有权

批量写日志或生成多条协议记录时，可以把一块工作缓冲区重置为零长度，再把结果复制或发送出去。复用的是切片容量，不代表结果可以在下一轮继续被修改；如果下游异步持有数据，就要转移所有权或复制一份。

package main

import "strconv"

// buildRecord 在已有工作区上构建一条记录，并返回独立结果。
func buildRecord(work []byte, name string, enabled bool) ([]byte, []byte) {
	// 只重置长度，保留容量供下一次构建使用。
	work = work[:0]
	work = append(work, name...)
	work = append(work, ':')
	work = strconv.AppendBool(work, enabled)

	// 下游若会异步持有结果，就复制出独立切片，避免下一轮覆盖它。
	result := append([]byte(nil), work...)
	return work, result
}

这里的复用边界比“保证零分配”更值得关注：工作区可以复用，但返回给异步消费者的 result 必须拥有自己的字节。是否真的减少分配，还要结合字符串转换、复制和下游接口的生命周期判断，不能只看一个 API 名称。

什么时候用 FormatBool，什么时候用 AppendBool

别把 AppendBool 当作“无条件零分配”开关：目标切片可能扩容，结果也可能需要复制。它的价值在于把布尔值直接接入字节构建链，减少为了中间 string 而产生的额外转换步骤。

常见问题

AppendBool 会返回除了 true 和 false 之外的内容吗？

不会。它按布尔值追加对应的文本，调用方需要关注的是返回切片和后续缓冲区生命周期。

预先分配容量后还要接返回值吗？

要。容量估算可能不准，字段名或后续内容也可能变长；统一接住返回值最安全。

AppendBool 一定比 FormatBool 快吗？

不能脱离场景下结论。已有字节缓冲区时它避免了中间字符串形态；如果接口本来就要字符串，FormatBool 更直接。需要量化差异时，应针对自己的输入长度和生命周期做基准测试。

小结：把布尔值追加到已有字节切片时使用 strconv.AppendBool，每次都接住返回值；循环复用缓冲区时明确结果所有权；需要 string 时选择 FormatBool。这样才是可维护的低分配写法。