Go base64.Encoding.DecodedLen 怎样估算解码缓冲区大小

在 Go 里用 Base64 解码时，DecodedLen 解决的是“目标缓冲区最多需要多大”，并不代表这次输入一定会产生同样多的有效字节。真正写入了多少，要看 Decode 返回的 n；如果输入有问题，还要同时处理返回的错误。

官方资料：https://pkg.go.dev/encoding/base64#Encoding.DecodedLen

DecodedLen(len(src)) 用来预留最大解码空间，Decode 返回实际写入长度；成功后应把目标切片截取为 dst[:n]，不要把整个容量当成有效数据。

DecodedLen 到底返回什么

官方定义是：Encoding.DecodedLen(n) 返回对应于 n 个 Base64 编码字节的最大解码长度。这里的关键词是“最大”和“编码字节数”，所以它是容量规划接口，不是对输入内容做完整解码后的结果查询。

以常见的标准编码为例，5 个字节编码后通常会得到 8 个字符，其中末尾可能包含补位字符。对长度为 8 的输入调用 StdEncoding.DecodedLen(8)，得到的是最多 6 个解码字节；实际数据可能只有 5 个字节。这个多出来的空间是补位规则带来的上限，不应直接当成业务数据。

StdEncoding 和 RawStdEncoding 的长度边界

StdEncoding 使用标准 Base64 表示，输出通常按 4 个字符一组并使用补位；RawStdEncoding 则是不带补位的变体。两者的 DecodedLen 都应通过各自的编码对象调用，不能拿一种编码的估算结果给另一种编码复用。

package main

import (
	"encoding/base64"
	"fmt"
)

func main() {
	// 标准编码的 8 个字符最多对应 6 个解码字节。
	stdMax := base64.StdEncoding.DecodedLen(8)

	// 无补位编码按自己的长度规则估算，不能套用标准编码的对象。
	rawMax := base64.RawStdEncoding.DecodedLen(7)

	fmt.Println("StdEncoding max:", stdMax)
	fmt.Println("RawStdEncoding max:", rawMax)
}

这里的重点不是记住某两个数字，而是让“编码对象”和“长度估算”保持配对。输入来自 URL、请求体或配置文件时，先确定它采用的是标准编码、URL 编码还是 Raw 变体，再调用对应对象的 DecodedLen。

Decode 要按实际写入长度截取结果

使用 Decode 时，目标切片的长度至少要能容纳 DecodedLen(len(src)) 个字节。解码成功后，返回值 n 才是本次真正写入的长度；应使用 dst[:n] 把可能多出的尾部空间排除掉。

package main

import (
	"encoding/base64"
	"fmt"
)

func decodeText(src string) ([]byte, error) {
	// 先按同一个 Encoding 计算最大空间，避免目标切片过小。
	dst := make([]byte, base64.StdEncoding.DecodedLen(len(src)))

	// n 是实际写入字节数，err 用来判断输入是否完整合法。
	n, err := base64.StdEncoding.Decode(dst, []byte(src))
	if err != nil {
		return nil, fmt.Errorf("decode base64: %w", err)
	}

	// 只把已经写入的部分交给调用方，不能返回整个 dst。
	return dst[:n], nil
}

如果把整个 dst 返回给调用方，尾部可能包含未使用的零值字节，后续写文件、比较摘要或解析协议时就会出现隐蔽错误。切片的长度和容量是两个概念：这里保留的是有效长度 n，不是把容量缩小。

输入错误时为什么可能有部分结果

官方文档说明，Decode 遇到非法 Base64 数据时，会返回已经成功写入的字节数和 CorruptInputError。因此不能只检查 n > 0 就把结果当成完整消息，也不能忽略 err。

func decodeStrict(src []byte) ([]byte, error) {
	// 估算值仍然只是最大空间，错误输入可能只写入前半段。
	dst := make([]byte, base64.StdEncoding.DecodedLen(len(src)))
	n, err := base64.StdEncoding.Decode(dst, src)
	if err != nil {
		// 记录 n 便于诊断，但不把部分结果冒充完整业务数据。
		return nil, fmt.Errorf("base64 input invalid after %d bytes: %w", n, err)
	}
	return dst[:n], nil
}

如果业务协议允许“尽可能读取前缀”，可以在明确记录错误的前提下保留 dst[:n]；如果业务要求完整消息，则应直接拒绝这次输入。这个决定属于调用方协议，不由 DecodedLen 自动替你做出。

已有前缀时用 AppendDecode

当目标切片里已经有前缀，AppendDecode 更适合把解码结果追加到已有数据后面。它返回扩展后的切片，调用方不需要手动计算写入起点，但仍然要检查错误，并决定是否接受部分追加结果。

func appendDecoded(prefix, encoded []byte) ([]byte, error) {
	// 先给已有前缀留在 dst 中，再追加本次解码结果。
	dst := append([]byte(nil), prefix...)
	dst, err := base64.StdEncoding.AppendDecode(dst, encoded)
	if err != nil {
		// 出错时返回 nil，避免调用方误用已经追加的部分内容。
		return nil, fmt.Errorf("append base64: %w", err)
	}
	return dst, nil
}

一张表记住调用边界

常见问题

DecodedLen 返回的长度就是最终数据长度吗？

不是。它表示最大解码长度，用来规划目标空间；最终有效长度要看 Decode 返回的 n，或者看 AppendDecode 返回切片的长度。

为什么 Decode 成功后还要写 dst[:n]？

因为预分配按最大长度完成，补位或编码边界可能让实际写入字节少于最大值。截取后，调用方看到的切片长度才等于有效数据长度。

遇到错误时能不能继续使用已经解码的前缀？

技术上可能存在部分写入，但是否可用取决于协议。完整消息场景应拒绝并记录错误；只有明确支持前缀恢复的场景，才可以同时保留实际写入长度和错误信息。

记住三件事即可：用匹配的 Encoding 调用 DecodedLen，把它当作最大空间；用 Decode 返回的 n 截取有效数据；任何错误都要单独处理，不能把部分写入当成完整解码结果。