Go base64.NewDecoder 读取到不完整结尾时怎么判断输入损坏

Go 的 base64.NewDecoder 读取流式输入时，判断“结尾不完整”不能只看 err != nil。对默认的带填充编码，底层 Reader 在一个 Base64 量子中途结束，解码器会把已经读到的片段视为截断，并返回 io.ErrUnexpectedEOF；如果读到非法字符，则通常是 base64.CorruptInputError。正确做法是先消费本次返回的 n 个字节，再用 errors.Is 或 errors.As 分层判断错误。

先分清完整量子、残缺量子与正常 EOF

NewDecoder 构造的是一个新的 Base64 流解码器，它会从传入的 io.Reader 中累积输入，再按量子解码。带填充的 StdEncoding 以四个字符为一个基本单元，因此输入在 QUJD 之后正常结束，和输入在 QUJ 处被截断，是两种不同状态。前者最终可以读到 io.EOF，后者应识别为意外结束。

这里的“结尾不完整”是编码结构不完整，不是输出缓冲区恰好被分成了多次 Read。网络 Reader 一次只返回几个字节很正常，解码器会继续补齐自己的输入缓冲；只有底层已经返回 EOF，而内部仍留有无法组成合法尾部的字节时，才进入截断判断。

用 errors.Is 和 errors.As 分层判断错误

推荐把错误判断写成两个层次：先判断是否为 io.ErrUnexpectedEOF，它表达“数据流提前结束”；再尝试提取 base64.CorruptInputError，它表达字符或填充位置不合法。底层 Reader 也可能返回自己的错误，这类错误不能被笼统归为 Base64 损坏。

package main

import (
    "encoding/base64"
    "errors"
    "fmt"
    "io"
    "strings"
)

func classify(encoded string) string {
    decoder := base64.NewDecoder(base64.StdEncoding, strings.NewReader(encoded))
    buf := make([]byte, 3)
    var output []byte
    for {
        n, err := decoder.Read(buf)
        // Read 可能同时给出有效字节和错误，先保存 n 个字节。
        output = append(output, buf[:n]...)
        if err == nil {
            continue
        }
        // UnexpectedEOF 表示带填充编码的尾部没有补齐，不等同于普通 EOF。
        if errors.Is(err, io.ErrUnexpectedEOF) {
            return fmt.Sprintf("truncated: %q", output)
        }
        var corrupt base64.CorruptInputError
        // CorruptInputError 带有非法输入位置，适合记录到排障日志。
        if errors.As(err, &corrupt) {
            return fmt.Sprintf("invalid at %d: %q", int64(corrupt), output)
        }
        if errors.Is(err, io.EOF) {
            return fmt.Sprintf("ok: %q", output)
        }
        return fmt.Sprintf("reader error: %v", err)
    }
}

func main() {
    for _, input := range []string{"QUJD", "QUJ", "QU$D"} {
        // 三个样本分别覆盖正常结尾、残缺量子和非法字符。
        fmt.Println(input, classify(input))
    }
}

示例中的判断顺序很重要：io.ErrUnexpectedEOF 是错误值语义，应该用 errors.Is；CorruptInputError 携带输入位置，应该用 errors.As。这样即使上层未来给错误加了包装，也不会因为字符串变化而失效。

处理 n 大于零且 err 同时返回的尾部

流式 API 的一个常见误区是看到错误就丢弃本次 Read 的结果。实际上，实现可以先把完整量子解码到调用方的缓冲区，再在下一次读取时报告底层结束；因此业务循环必须遵守“先处理 n，再处理 err”。若协议要求消息必须完整，应该把这些字节放入临时缓冲，直到确认最终是 io.EOF 后再提交；若允许前缀恢复，则可以在记录错误后保留已经解码的数据。

不要用“读到的字节数少于缓冲区长度”判断损坏，因为短读可能只是 Reader 的正常分片。也不要把所有 EOF 都当成成功：只有没有遗留残片的普通 io.EOF 才代表完整结束；带残片的 EOF 会升级为 io.ErrUnexpectedEOF。

把编码模式和验证策略固定下来

落地时可以固定四项检查：第一，发送端和接收端约定使用 StdEncoding 还是 RawStdEncoding；第二，生产日志记录错误类型和非法位置，不只记录“解码失败”；第三，完整消息在临时缓冲中通过校验后再写入最终目标；第四，为空输入、完整量子、残缺量子、非法字符和底层 Reader 错误各留一个回归样本。

一句话总结：NewDecoder 的尾部判断要围绕“内部是否还剩不能组成合法量子的输入”展开。正常 EOF 是完整结束，UnexpectedEOF 是提前截断，CorruptInputError 是内容不合法；三者分开处理，才能既不误报网络分片，也不把损坏数据提交给后续业务。

相关问题

为什么一次 Read 返回 n=0、err=nil 不能直接判定失败？

Reader 允许暂时没有产出，解码器也可能仍在补齐自己的缓冲。应继续读取，直到拿到数据、EOF 或其他明确错误。

RawStdEncoding 也会返回 UnexpectedEOF 吗？

无填充模式允许合法的短尾部，因此结尾判断与 StdEncoding 不同；仍应让解码器返回值决定结果，不要仅按长度猜测。

拿到 CorruptInputError 后还能使用部分输出吗？

可以读取已经返回的前缀，但是否提交取决于协议。对完整性敏感的消息，应把整条消息视为失败并丢弃临时缓冲。