Go base64.Encoding.AppendEncode 如何复用缓冲区：容量增长与编码边界

做短期令牌拼接时，很多 Go 代码先把字节切片转成 Base64 字符串，再和前缀拼接，结果既多了一次分配，也让输出缓冲区的归属变得模糊。Go 1.22 引入的 base64.Encoding.AppendEncode 可以直接把编码结果接到已有 dst 后面；真正需要看清的是，它追加的是编码后的字节，不会覆盖 dst 原有前缀。

把 dst 当成输出缓冲区传入，AppendEncode 返回包含前缀和编码结果的新切片；有足够容量时可以复用底层数组，容量不足时则由追加操作扩容。

先把 dst、src 和返回值放到同一条数据路径

这个 API 最容易被误读成“把 src 编码到 dst”。更准确的描述是：AppendEncode 读取 src，把编码结果追加到 dst 的尾部，并返回新的切片。下面的例子用 token: 作为前缀，便于直接观察数据路径。

package main

import (
    "encoding/base64"
    "fmt"
)

func main() {
    dst := []byte("token:")
    src := []byte("go-44")

    encoded := base64.StdEncoding.AppendEncode(dst, src)

    fmt.Printf("%q\\n", encoded)
    fmt.Printf("prefix=%q, added=%d\\n", encoded[:len(dst)], len(encoded)-len(dst))
}

运行后可以看到 encoded 同时包含 token: 和 Base64 结果，dst 的原长度仍然是追加起点。这里保存返回值很关键：如果后续只使用旧变量 dst，自然看不到新追加的尾部。

AppendEncode 怎么保留已有 dst 前缀

dst 不是一个必须为空的目标数组，它可以已经装有协议前缀、版本字节或字段名。调用时，AppendEncode 从 len(dst) 的位置继续写入；返回的 encoded 才是完整结果。

这条关系适合用在一个请求体由多个字段拼成的场景。例如先追加固定字段，再追加一次编码值：

dst := make([]byte, 0, 32)
dst = append(dst, "token:"...)
encoded := base64.RawURLEncoding.AppendEncode(dst, []byte("go-44"))

fmt.Println(string(encoded))

无论底层数组是否发生扩容，返回切片中的顺序都一样：先是 dst 原有内容，后是编码后的 src。区别只在于容量和底层数组是否被复用。

用 EncodedLen 预留空间，别拿输入长度猜输出

Base64 会把二进制数据映射成更长的文本字节。输入长度为 1、2、3 时，标准编码分别需要 4、4、4 个字节；更长输入也按 4 字节块输出。因此，预留空间要调用 EncodedLen，而不是直接给 src 的长度。

src := []byte("go-44")
prefix := []byte("token:")

need := len(prefix) + base64.StdEncoding.EncodedLen(len(src))
dst := make([]byte, 0, need)
dst = append(dst, prefix...)
encoded := base64.StdEncoding.AppendEncode(dst, src)

fmt.Printf("len(src)=%d, EncodedLen=%d, cap(dst)=%d\\n",
    len(src), base64.StdEncoding.EncodedLen(len(src)), cap(dst))
fmt.Println(string(encoded))

这里的 len(src) 只表示原始输入字节数，EncodedLen 表示新增编码结果所需的最大精确长度，cap(dst) 则决定追加时是否还有可复用空间。三者含义不同，日志里最好分开打印。

容量不足时发生什么，返回值为什么不能丢

如果 cap(dst)-len(dst) 小于编码结果需要的空间，追加过程会分配更大的底层数组，并把旧内容复制过去。这个行为不会改变编码结果，但可能让原来与 dst 共享数组的其他切片继续指向旧数组。

所以，容量复用是优化机会，不是调用契约。业务代码应始终接住返回值：

dst := []byte("token:")
encoded := base64.StdEncoding.AppendEncode(dst, []byte("go-44"))

// 正确：继续使用 encoded
send(encoded)

func send(payload []byte) {
    fmt.Println(string(payload))
}

如果需要多次追加，应把每次返回值继续传给下一次调用；不要假设某个初始容量永远够用。对复用型缓冲区，建议在基准测试中观察分配次数，而不是凭感觉写一个很大的容量。

空输入、填充和 RawURLEncoding 的边界

空的 src 不会新增字节，返回结果仍保留 dst。使用 base64.StdEncoding 时，输出遵循标准 Base64 字母表并按需要带 = 填充；使用 base64.RawURLEncoding 则采用 URL 安全字符并省略填充。选择哪一个，要看接收端的协议约定。

prefix := []byte("v1:")
std := base64.StdEncoding.AppendEncode(prefix, []byte{0xff, 0xee})
rawURL := base64.RawURLEncoding.AppendEncode(prefix, []byte{0xff, 0xee})

fmt.Println(string(std))
fmt.Println(string(rawURL))

这两个调用都遵守同一条追加规则，但结果的字母表和尾部格式不同。不要只因为结果能被某个解码器读回，就认为它符合接口协议；先确认对端约定的是标准、原始、URL 安全还是自定义字母表。

常见问题

AppendEncode 会修改传入的 dst 吗？

当容量足够时，它可能直接写入 dst 共享的底层数组；当容量不足时会返回扩容后的切片。调用方不应依赖底层数组是否更换，只应使用返回值。

为什么不用 EncodeToString？

如果最终目标就是字符串，EncodeToString 更直接；如果结果要继续拼到已有字节缓冲区，AppendEncode 能表达追加关系，并可配合容量预留减少分配。

EncodedLen(len(src)) 是不是实际输出长度？

对给定编码方式，它返回输入长度对应的编码长度。标准 Base64 会包含填充；Raw 编码关闭填充后，长度规则会不同，因此应对实际使用的 Encoding 调用它。

把这条边界带回代码审查

看到 AppendEncode 时，先检查三件事：是否接住了返回值，是否用正确的 Encoding，是否用 EncodedLen 而不是原始长度估算空间。这样既能保留前缀，也能让容量复用和扩容行为落在可验证的范围内。