Go Base32 不完整尾组却解码成功：检查数据与 EOF 同次返回

同一段 Base32 文本，用 strings.Reader 解码报 unexpected EOF，换成 gzip.Reader 或 HTTP 响应体后却返回成功，还只得到前面一部分数据。若输入末尾不足一个完整编码组，应检查底层 Read 是否把最后一批数据与 io.EOF 一起返回。

Go 1.27.2 的明确组合包括 AAAAAAAAA 与 MZXW6===A：前者多了一个不完整字符，后者在已填充的编码组后还有残余字符。base32.NewDecoder 对不同分块方式给出不一致结果；不能因为 err 为 nil 就认定编码文本已经完整校验。

Read 可以同时返回数据和 EOF

io.Reader 允许一次返回 n > 0 和 io.EOF。消费方需要先处理这 n 个字节，再处理结束状态；gzip、HTTP 与测试用 reader 都可能采用这种合法返回方式。

Go 1.27.3 的正式 Base32 流式解码实现仍有这条路径：保存读到的 EOF，解码完整的八字符组，把剩余字符留在缓冲中，随后以保存的错误结束。EOF 与数据同批到达时，不完整尾组可能没有再经过校验。实际表现仍须按所用版本、输入和 reader 核对。

先保留编码模式、实际输入长度及生产 reader 类型，在已有隔离测试中覆盖“尾数据与 EOF 同次返回”和“另一次才返回 EOF”。单纯把 gzip.Reader 换成 strings.Reader 能改变表现，却没有修复真实数据源的消费路径。

小而有界的数据可先读全，再一次解码

如果协议本来就限制了编码文本大小，可以先按上限完整读取，再用相同 Encoding 的 DecodeString。下面是返回 ([]byte, error) 的现有函数内片段，input 是已获得的 reader，使用 encoding/base32、fmt 和 io：

const maxEncoded = 1 << 20
encoded, err := io.ReadAll(io.LimitReader(input, maxEncoded+1))
if err != nil {
    return nil, err
}
if len(encoded) > maxEncoded {
    return nil, fmt.Errorf("base32 input exceeds %d bytes", maxEncoded)
}
decoded, err := base32.StdEncoding.DecodeString(string(encoded))
if err != nil {
    return nil, err
}
return decoded, nil

1MiB 仅为示例预算，应按协议和并发内存限制选择；它不是 Base32 的格式上限。多读一个字节是为了识别超限，不能只读到上限就把被截断的数据当作完整消息。input 的关闭和请求取消仍由原有所有者处理，LimitReader 不会接管资源。

这条具体绕行适用于上面带标准填充的输入。原协议若使用自定义字母表或 NoPadding，必须继续使用相同 Encoding 并另核它的边界，不能为了消除错误切换模式。也不要先 TrimSpace、丢掉尾部字符或在失败时保留部分输出。

不受控的大文件和持续流不适合整段缓冲。它们需要保留真正的流式预算，并使用已经验证能检查结束状态的解码路径；不能把示例的 1MiB 改成任意大数，就当作通用流式修复。

验收同时覆盖正常输入、不完整尾组、填充后多余字符和两种 EOF 分块方式，确认非法输入不会以部分结果成功交给业务。这里解决的是具体尾组漏检，不承诺一次解码接口已经覆盖所有其他 Base32 格式缺陷；升级后仍要检查实际正式版本及原协议样例。