Go encoding/base64.AppendEncode 怎样复用目标字节切片

如果一个接口已经有了响应前缀、字段名或协议头，Base64 结果不必先变成 string 再拼回字节切片。encoding/base64 的 AppendEncode 会把编码后的内容追加到 dst，并返回扩展后的切片；调用方只要接住返回值，就能保留原有前缀并继续复用缓冲区。

官方文档：https://pkg.go.dev/encoding/base64#Encoding.AppendEncode

AppendEncode 和 EncodeToString 的差别是什么

EncodeToString 适合“输入字节直接得到一个字符串”的场景，而 AppendEncode 的签名是 AppendEncode(dst, src []byte) []byte：它把结果放到已有字节切片后面，返回扩展后的切片。这个差异对 HTTP 头片段、日志缓冲或自定义二进制协议很重要，因为中间不必先创建字符串再转换成字节。

官方文档把它定义为追加 Base64 编码结果的操作；它本身不返回 error，输入任意字节都可以编码。真正需要检查的是调用方有没有保存返回值，以及接收方是否要求填充字符。

dst 有前缀时怎样保留原内容

dst 的长度决定“从哪里开始追加”，容量决定“是否有机会在原底层数组上继续写”。因此，前缀不能只放进容量而不放进长度；否则编码结果会覆盖调用方以为已经存在的内容。最稳妥的写法是用真实前缀初始化切片，并把返回值重新赋给同一个变量。

package main

import (
    "encoding/base64"
    "fmt"
)

func appendToken(prefix, payload []byte) []byte {
    // prefix 的长度代表已经写入的协议内容，容量额外留给 Base64 结果。
    dst := make([]byte, len(prefix), len(prefix)+base64.StdEncoding.EncodedLen(len(payload)))
    copy(dst, prefix)

    // AppendEncode 从 dst 的当前长度开始追加，必须接住返回值。
    return base64.StdEncoding.AppendEncode(dst, payload)
}

func main() {
    // 示例只展示字节切片组合，不代表某个线上协议的固定格式。
    result := appendToken([]byte("token="), []byte("go"))
    fmt.Println(string(result))
}

这里的关键不是把 dst 预分配得很大，而是让它同时拥有正确的长度和足够的容量。即使容量不足，AppendEncode 也会返回可用的新切片；只要保存返回值，代码的正确性不会依赖底层数组是否发生迁移。

怎样按 EncodedLen 预留容量

Base64 每三字节通常对应四个输出字节，最后一组还可能产生填充，因此不要手写“输入长度乘四再除三”的近似公式。直接调用同一个编码对象的 EncodedLen，再把它加到已有长度上，表达更清楚，也能跟当前编码对象的填充策略保持一致。

func appendFields(dst []byte, fields ...[]byte) []byte {
    // 先计算本轮编码结果的总容量，避免每次追加都让切片反复扩容。
    extra := 0
    for _, field := range fields {
        extra += base64.RawStdEncoding.EncodedLen(len(field))
    }
    out := make([]byte, len(dst), len(dst)+extra)
    copy(out, dst)

    for _, field := range fields {
        // RawStdEncoding 不带 '=' 填充，适合已有明确无填充约定的字段。
        out = base64.RawStdEncoding.AppendEncode(out, field)
    }
    return out
}

这个例子把多个字段连续追加到一个切片中。是否应该把多个字段连在一起，取决于协议有没有字段分隔符；Base64 编码本身不会替调用方保留字段边界。如果接收端需要逐字段解码，就应在字段之间明确写入分隔符或长度信息。

StdEncoding、RawStdEncoding 和 URLEncoding 怎么选

编码对象决定字符表和填充策略。标准编码使用 +、/，默认带 = 填充；URL 编码把这两个字符替换为 -、_；Raw 版本去掉填充。它们不是可以随意互换的显示格式，接收端必须按同样的约定解码。

哪些调用细节最容易写错

• 忽略返回值：如果 dst 容量不足，旧变量可能仍指向旧底层数组，后续读取会看不到完整结果。
• 把容量当长度：make([]byte, 0, n) 是空切片，适合从零追加；它不会自动包含任何前缀字节。
• 混用编码对象：用 RawStdEncoding 编码，却让接收端按带填充的标准编码解码，边界数据尤其容易出问题。
• 误以为追加等于分隔：连续追加两个输入只会形成一串编码文本，不能让解码方自动知道两个输入在哪里切开。

因此可以把判断顺序固定为：先确认接收协议的编码对象，再决定 dst 是否带前缀；有多次追加时用 EncodedLen 估算容量；最后始终保存 AppendEncode 的返回值。

常见问题

AppendEncode 会修改传入的 dst 吗？

它会把结果追加到 dst 的逻辑末尾，可能复用其底层数组，也可能因为容量不足分配新数组。调用方应只依赖返回的扩展切片，不应依赖底层数组地址是否保持不变。

为什么不直接用 Encode 写入预分配数组？

Encode 面向一个已经准备好输出空间的目标切片，而 AppendEncode 面向已有内容后继续追加。两者都能复用内存，但目标切片的长度语义不同，不能把一个 API 的用法直接套到另一个 API 上。

RawStdEncoding 是否总是更省空间？

它只是不写末尾填充字符，不代表所有协议都应该使用它。能否省略填充要看接收端的解码约定；如果协议要求标准 Base64，就应保留 StdEncoding 的默认格式。