Go base32.NewDecoder 怎么流式解码大内容

base32.NewDecoder 的正确用法是把它当作一个 io.Reader 适配层：底层 Reader 持续提供 Base32 文本，解码器按块产出原始字节，再交给 io.Copy 或 io.CopyBuffer 写入文件、哈希器或其他 Writer。这样无需先用 io.ReadAll 把整段编码内容放进内存，适合处理大文件和长响应体。

Go 官方文档：https://pkg.go.dev/encoding/base32

把 NewDecoder 放进 Reader 链

base32.NewDecoder(enc, r) 返回的是 io.Reader，不是一次性返回 []byte 的函数。它内部只保留解码所需的小块输入、少量剩余输出和错误状态。调用方每次读取一部分，解码器就向底层 Reader 请求下一块数据，因此整体内存不会随着完整输入大小线性增长。

这也是它与 DecodeString 的关键区别：后者适合已经完整存在于内存中的短文本；前者适合文件、HTTP Body、管道或对象存储下载流。不要先 io.ReadAll 再创建 Decoder，那会把流式接口重新变成一次性内存操作。

最小可用写法：从大文件解码到另一个文件

下面的函数打开编码文件，用 NewDecoder 包装输入，再持续写入目标文件。32 KiB 只是一个常用的复制缓冲大小，不是 Base32 协议要求；如果源实现了 WriterTo 或目标实现了 ReaderFrom，io.CopyBuffer 还可能使用接口提供的优化路径。

package main

import (
    "encoding/base32"
    "fmt"
    "io"
    "os"
)

func decodeBase32File(srcPath, dstPath string, enc *base32.Encoding) (err error) {
    src, err := os.Open(srcPath)
    if err != nil {
        return fmt.Errorf("打开 Base32 输入失败: %w", err)
    }
    defer src.Close()

    dst, err := os.Create(dstPath)
    if err != nil {
        return fmt.Errorf("创建输出文件失败: %w", err)
    }
    defer func() {
        // 保留前面出现的错误；只有复制成功时才返回关闭错误
        if closeErr := dst.Close(); err == nil && closeErr != nil {
            err = fmt.Errorf("关闭输出文件失败: %w", closeErr)
        }
    }()

    // Decoder 是 Reader，可直接接入标准库复制链
    decoder := base32.NewDecoder(enc, src)
    buf := make([]byte, 32*1024)
    if _, err := io.CopyBuffer(dst, decoder, buf); err != nil {
        return fmt.Errorf("流式解码失败: %w", err)
    }
    return nil
}

调用时通常选择 base32.StdEncoding、base32.HexEncoding，或双方约定的自定义 Encoding。NewDecoder 本身没有 Close 方法；需要关闭的是底层文件、网络响应体和目标文件。解码是否成功由读取链最终返回的错误决定。

编码表和 Padding 不一致会怎样

流式处理不会自动识别输入使用哪套 Base32 字母表。发送端用 StdEncoding，接收端就不能改用 HexEncoding；发送端调用了 WithPadding(base32.NoPadding)，接收端也要使用相同设置。否则常见结果是 CorruptInputError、意外 EOF，或解码得到错误字节。

var tokenEncoding = base32.
    NewEncoding("0123456789ABCDEFGHJKMNPQRSTVWXYZ").
    WithPadding(base32.NoPadding)

func newTokenDecoder(src io.Reader) io.Reader {
    // 接收端必须复用与发送端完全一致的字母表和无填充规则
    return base32.NewDecoder(tokenEncoding, src)
}

Base32 解码会忽略回车和换行，因此 MIME 风格的折行文本可以直接读取；空格、制表符和其他不在字母表中的字符不会被自动忽略。对默认有填充的 Encoding，结尾必须满足合法的 8 字符量子和填充形式。流在中途被截断时，错误可能表现为 io.ErrUnexpectedEOF 或非法 Base32 数据。

给不可信大输入加上双重限额

“流式”只表示不一次性占用全部内存，并不代表可以无限接收数据。网络客户端、上传接口或消息系统中的 Base32 内容仍可能持续消耗带宽、CPU 和磁盘。更稳妥的做法是同时限制编码输入和解码输出：前者阻止无限读取，后者保护目标存储。由于 Base32 文本还可能包含可忽略的 CR/LF，两类限制不应互相替代。

下面的函数把输出先写入同目录临时文件。只有解码、大小检查、同步和关闭全部成功后，才通过 os.Rename 提交最终路径；任何失败都会删除半成品。

package main

import (
    "encoding/base32"
    "errors"
    "fmt"
    "io"
    "os"
    "path/filepath"
)

func decodeAtomically(
    src io.Reader,
    finalPath string,
    enc *base32.Encoding,
    maxEncoded int64,
    maxDecoded int64,
) (err error) {
    // 多读 1 字节，用于区分“刚好到上限”和“已经超限”
    limitedSource := &io.LimitedReader{R: src, N: maxEncoded + 1}
    decoder := base32.NewDecoder(enc, limitedSource)
    limitedDecoded := &io.LimitedReader{R: decoder, N: maxDecoded + 1}

    tmp, err := os.CreateTemp(filepath.Dir(finalPath), ".base32-decoded-*")
    if err != nil {
        return fmt.Errorf("创建临时文件失败: %w", err)
    }
    tmpName := tmp.Name()
    committed := false
    defer func() {
        // 错误路径关闭并删除半成品，避免被后续流程误用
        _ = tmp.Close()
        if !committed {
            _ = os.Remove(tmpName)
        }
    }()

    buf := make([]byte, 32*1024)
    n, err := io.CopyBuffer(tmp, limitedDecoded, buf)
    if err != nil {
        return fmt.Errorf("Base32 数据不完整或格式错误: %w", err)
    }
    if n > maxDecoded {
        return fmt.Errorf("解码结果超过 %d 字节", maxDecoded)
    }
    if limitedSource.N == 0 {
        return fmt.Errorf("编码输入超过 %d 字节", maxEncoded)
    }

    // 只有完整结果才同步、关闭并替换最终文件
    if err := tmp.Sync(); err != nil {
        return fmt.Errorf("同步临时文件失败: %w", err)
    }
    if err := tmp.Close(); err != nil {
        return fmt.Errorf("关闭临时文件失败: %w", err)
    }
    if err := os.Rename(tmpName, finalPath); err != nil {
        return fmt.Errorf("提交最终文件失败: %w", err)
    }
    committed = true
    return nil
}

func isBadBase32(err error) bool {
    var corrupt base32.CorruptInputError
    // errors.As 可以识别包装后的非法输入错误
    return errors.As(err, &corrupt) || errors.Is(err, io.ErrUnexpectedEOF)
}

如果最终路径可能已存在，需要结合当前平台的重命名语义设计覆盖策略；如果临时目录和目标目录不在同一文件系统，Rename 也可能失败。把临时文件建在最终路径所在目录，可以减少跨文件系统移动问题。

不要忽略 io.Copy 已经写出的部分数据

Base32 解码器可能在发现非法字符前已经产出一部分合法字节。标准库的 Decode 与 DecodeString 文档也明确说明，输入畸形时会返回部分解码数据和错误。流式 Reader 同样可能先让目标收到若干字节，然后在后续读取中返回错误。

因此，直接写最终文件时，io.Copy 返回错误并不表示目标还是空的。若业务把文件是否存在当作“已成功”的标志，就可能误消费半成品。临时文件 + 成功后 Rename 的模式，保护的不只是磁盘空间，也保护结果的完整性。

为错误补上阶段信息

生产代码不应只返回一句“decode failed”。至少区分四类上下文：底层读取失败、Base32 格式错误、目标写入失败、最终提交失败。CorruptInputError 的错误文本会指出非法数据所在的输入字节位置，但在流式、多行或带外层协议的场景中，仍应同时记录对象标识、Encoding 名称、限制值和已经写入的字节数，避免记录完整敏感内容。

io.Copy 在正常读到 EOF 时返回的 error 是 nil，而不是 io.EOF。所以调用方只需要检查非 nil 错误，不要把 nil 当成“没有读到结尾”。相反，如果自己手写 Read 循环，应遵守 n > 0 时先处理数据，再判断 error 的 Reader 约定。

上线前快速检查

• 输入是否直接交给 NewDecoder，而不是先 ReadAll？
• 发送端和接收端的 Encoding、字母表与 Padding 是否一致？
• 是否持续读取到 EOF，并检查 io.Copy/io.CopyBuffer 的返回错误？
• 外部输入是否同时设置编码字节和解码字节上限？
• 错误时是否清除部分输出，成功后才暴露最终文件？
• 底层 Reader、响应体和目标文件是否由明确的一方关闭？

常见问题

NewDecoder 需要 Close 吗？

不需要，它返回的是 io.Reader。但底层文件或 HTTP Body 仍要关闭，目标文件也要在写入后关闭并检查错误。

为什么使用 NewDecoder 后内存还是很高？

常见原因是上游先调用了 io.ReadAll，或下游写入了 bytes.Buffer 并最终把全部结果留在内存。流式链的每一段都要避免无界缓存。

Base32 文本中有换行要先清理吗？

通常不用，标准库解码会忽略 CR 和 LF。其他空白字符不会自动忽略，输入协议若允许它们，应在进入 Decoder 前做明确、受限的规范化。

io.CopyBuffer 的缓冲区越大越快吗？

不一定。文件和网络实现可能走 WriterTo 或 ReaderFrom 优化而不使用提供的缓冲区；即使使用，过大的缓冲区也会增加并发任务的总内存占用。应结合实际 I/O 和并发量测试。