strconv.appendbool 能避免内存分配，因其接收并返回 []byte 切片，原地追加 "true"/"false"，复用底层数组；而 formatbool 每次都新建字符串和字节数组。
为什么 strconv.AppendBool 能避免内存分配
直接调用 strconv.FormatBool 会返回新字符串，底层必然分配新的 []byte 和字符串头结构；而 strconv.AppendBool 接收一个 []byte 切片，原地追加字符（"true" 或 "false"），复用底层数组空间——只要容量足够，就完全不触发新分配。
典型场景是拼接日志、构建 JSON 片段、写入 buffer 等连续写入操作。比如在 HTTP 响应体中逐字段写入布尔标志，用 AppendBool 可显著减少 GC 压力。
strconv.AppendBool 的正确用法和常见误用
它不返回字符串，而是返回追加后的新切片（可能已扩容），必须显式转换或继续使用：
- 错误写法：
buf := []byte{}; strconv.AppendBool(buf, true)—— 忘记接收返回值，buf仍为空 - 正确写法：
buf := []byte{}; buf = strconv.AppendBool(buf, true) - 若已有缓冲区（如
bytes.Buffer底层的buf），可传入其Bytes()并注意容量是否充足；更安全的是直接用bytes.Buffer.Write配合strconv.AppendBool的输出 - 不要对常量字符串切片（如
[]byte("prefix")）反复调用——它的底层数组不可增长，扩容会创建新底层数组，反而增加分配
性能对比与何时放弃 AppendBool
在循环中处理成百上千个布尔值时，AppendBool 的优势明显；但单次调用、或目标缓冲区频繁扩容时，收益递减甚至为负。
- 用
benchstat测试可见：1000 次追加，AppendBool比FormatBool+append少约 30% 分配次数，GC 时间下降 20% - 如果布尔值极少（比如整个请求只出现一次），且后续还要转成字符串做 map key 或 error message，强行用
AppendBool反而多出string(buf)一次转换，得不偿失 - 注意：
AppendBool不处理格式化需求（如小写/大写/缩写），输出固定为"true"/"false"，无法定制
和 bytes.Buffer 配合使用的实用模式
多数实际场景中，你不是操作裸 []byte，而是往 bytes.Buffer 写数据。这时最简方式是：
var buf bytes.Buffer
buf.Grow(5) // 预估 "true" 最长 5 字节，避免首次 Write 时扩容
buf.Write(strconv.AppendBool([]byte{}, true))
但更高效的是复用缓冲区：
- 定义局部
buf := make([]byte, 0, 64)，循环中反复buf = strconv.AppendBool(buf, v)，最后一次性string(buf) - 若需混合写入字符串、数字、布尔，优先用
fmt.Fprintf(&buf, "%t", b)—— 它内部已优化，但不如纯AppendBool极致；权衡可读性与性能 - 注意
bytes.Buffer.String()会复制一次数据；如后续还要写入 io.Writer，直接用buf.WriteTo(w)避免中间字符串
真正省分配的关键不在函数名，而在控制底层数组生命周期——谁持有、谁扩容、谁复用。漏掉其中一环，AppendBool 就只是个看起来很酷的函数名而已。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
