Go base64.NewEncoder 关闭前不调用 Close 会少多少数据

我第一次遇到这个问题是在把分段数据写进一个 Base64 字段时：前面的内容都能解码，只有最后几个字符不见了。原因不是 base64.StdEncoding 随机丢数据，而是 base64.NewEncoder 还把不足 3 个字节的尾部留在内部缓冲里。没有调用 Close，这段尾部就不会写入目标 io.Writer。

使用标准带填充编码时，输入长度除以 3 的余数为 1 或 2，忘记 Close 通常会少 4 个输出字符；余数为 0 时没有待刷的尾块，但仍应把 Close 当作流结束动作并检查错误。

先从缺少尾部字符的症状确认影响

Base64 把 3 个输入字节编码成 4 个输出字符。流式编码如果在最后一次 Write 后直接读取目标缓冲区，就可能只看到已经凑齐的完整块。可以先按输入长度的余数判断影响：

所以标题里的“少多少”不是固定少 1 个原始字节，而是少掉尾部的 Base64 表示。若使用 RawStdEncoding 关闭填充，余数为 1 时会少 2 个字符，余数为 2 时会少 3 个字符。这个差异很适合写进回归测试。

为什么 Write 成功了，尾部却还没有写出

NewEncoder 返回的是 io.WriteCloser。实现内部有一个 3 字节缓冲：Write 会优先补齐已有尾部，随后处理能组成完整块的数据，最后把不足 3 字节的部分留待后续输入。也就是说，Write 返回成功只代表输入已被编码器接收，不等于所有编码结果都已写入底层 Writer。

官方文档明确要求在写完后关闭编码器，以刷新部分块。源码中的 Close 会对缓冲区剩余的 1 或 2 个字节调用编码逻辑，再把 EncodedLen 对应的尾部写入目标。这个边界也解释了为什么用 Encode 逐块替代流式编码容易把填充和块边界处理复杂化。

用显式 Close 和错误检查修复流式编码

不要把编码器当成只需要 Write 的普通 Writer。结束时显式关闭，并且不能忽略 Close 的错误，因为尾部写入发生在这里，底层文件、网络响应或自定义 Writer 可能恰好在最后一次写入时失败。

package main

import (
	"bytes"
	"encoding/base64"
	"fmt"
)

func encodeStream(parts [][]byte) (string, error) {
	var dst bytes.Buffer
	encoder := base64.NewEncoder(base64.StdEncoding, &dst)

	for _, part := range parts {
		// Write 成功只表示数据进入编码器，尾部可能仍在内部缓冲。
		if _, err := encoder.Write(part); err != nil {
			return "", fmt.Errorf("写入 Base64 编码器失败: %w", err)
		}
	}
	// Close 负责刷新最后不足三个字节的部分，并返回底层 Writer 错误。
	if err := encoder.Close(); err != nil {
		return "", fmt.Errorf("关闭 Base64 编码器失败: %w", err)
	}
	return dst.String(), nil
}

如果目标是 HTTP 响应或文件，调用顺序也一样：先完成全部 Write，再 Close，最后再认为编码结果完整。若中途 Write 已返回错误，不应继续把半成品当成可发布数据。

用长度和解码结果覆盖三个边界

回归测试不要只选 3、6、9 这类整块长度。至少准备空输入、长度余数为 1、长度余数为 2，以及跨多次 Write 才凑齐 3 字节的输入。断言编码字符串长度，同时把结果解码回原始字节，才能同时发现“尾部没刷出”和“数据内容被改写”。

重点检查两件事：第一，标准编码的结果长度应符合 base64.StdEncoding.EncodedLen(len(input))；第二，DecodeString 后得到的字节必须与原输入相等。还可以在测试中故意注释掉 Close，确认余数为 1 或 2 时长度短 4，从而让这个坑不会悄悄回归。

常见问题与边界

输入长度是 3 的倍数，还必须 Close 吗？

从当前实现看，没有待刷尾块时不会额外产生字符，但接口契约仍要求写完后 Close。统一执行结束动作，也能让错误处理和未来替换编码器保持一致。

用 defer encoder.Close() 可以吗？

可以保证调用发生，但如果 Close 错误会被忽略。对文件和网络输出，建议像示例一样显式处理；只有能接受丢失尾部错误的场景才考虑简单 defer。

RawStdEncoding 为什么少的字符数不同？

它关闭了 = 填充，所以余数为 1 的尾块只有 2 个字符，余数为 2 的尾块只有 3 个字符。是否使用 raw 编码要由接收方协议约定，不能靠删除末尾填充临时修复。