Base64编码缓冲区为何大于原文本长度及EncodedLen性能疑问

1. 缓冲区大小不足的问题 #

Base64编码的核心规则是每3字节原始数据对应4字节编码结果，如果原始数据长度不是3的整数倍，会用=填充至4字节的倍数。所以直接用len(text)创建缓冲区，空间必然不够——比如1字节原始数据编码后需要4字节，2字节原始数据编码后也需要4字节，4字节原始数据编码后需要8字节。

正确的做法是使用base64.StdEncoding.EncodedLen(len(text))计算所需缓冲区大小，这个函数会精准返回编码后的字节数，彻底避免缓冲区溢出或数据截断。

反例（会触发panic）：

text := []byte("hello")
buf := make([]byte, len(text)) // len(text)=5，编码后实际需要8字节，缓冲区空间不足
base64.StdEncoding.Encode(buf, text)

正确写法：

text := []byte("hello")
buf := make([]byte, base64.StdEncoding.EncodedLen(len(text))) // 返回8
base64.StdEncoding.Encode(buf, text)
// 编码结果正确："aGVsbG8="

2. EncodedLen的性能开销问题 #

完全不需要担心这个函数的性能——它本质就是一个纯整数数学运算，没有任何内存分配、系统调用或复杂逻辑。Go标准库中EncodedLen的实现非常简洁：

func (enc *Encoding) EncodedLen(n int) int {
	return (n + 2) / 3 * 4
}

这种运算的耗时可以忽略不计。相比你手动计算（还要处理各种边界情况），直接使用官方实现不仅更可靠，也不存在任何额外性能开销。

内容的提问来源于stack exchange，提问作者aronchick