Go base64.Encoding.Strict 遇到非零填充位时的解码排查

Go 的 Base64 字符串看起来合法，不代表它满足严格的 RFC 4648 填充规则。base64.Encoding.Strict() 会复制一个编码对象，并要求最后一个量子中没有被编码数据占用的填充位必须为 0；因此像 SB== 这样的输入，可能在普通解码路径下没有明显问题，却在严格解码时返回 CorruptInputError。

官方文档：https://pkg.go.dev/encoding/base64#Encoding.Strict

Go base64.Encoding.Strict 具体检查什么

Base64 每 3 个字节编码成 4 个字符。输入长度不是 3 的整数倍时，最后一组字符里有一部分比特只用于补齐编码格式，并不承载原始数据。规范要求这些“填充位”为零，普通的 Encoding 不会额外拒绝非零填充位，而 Strict 会检查它们。

例如，一个字节 H 的规范 Base64 是 SA==。第二个字符中只有高两位继续表达原始数据，低四位属于填充位，应该是 0。把它改成 SB== 后，字符仍在 Base64 字母表内，但填充位变成了非零值，这正是严格模式要拦截的边界。

用 CorruptInputError 找到非零填充位

排查时不要只看“解码失败”四个字。先用严格编码对象调用 DecodeString，再用 errors.As 把错误还原成 base64.CorruptInputError。错误值表示输入中的位置，适合把问题落到原始字段或传输片段。

package main

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

func main() {
    strict := base64.StdEncoding.Strict()
    samples := []string{"SA==", "SB==", "S A=="}

    for _, text := range samples {
        decoded, err := strict.DecodeString(text)
        if err == nil {
            // 成功结果只取解码返回的字节，不把输入字符串当作可信数据。
            fmt.Printf("%q -> %q\n", text, decoded)
            continue
        }

        var corrupt base64.CorruptInputError
        if errors.As(err, &corrupt) {
            // 记录索引，便于回到原始请求或消息中定位坏量子。
            fmt.Printf("%q -> invalid at byte %d: %v\n", text, int64(corrupt), err)
            continue
        }
        // 处理无法归类为输入位置的其他错误，避免静默丢弃。
        fmt.Printf("%q -> decode failed: %v\n", text, err)
    }
}

示例中的空格不是填充位问题，而是输入形态问题：Base64 解码器会忽略 CR 和 LF，但不会把普通空格当作换行。日志或接口字段若经过折行，先确认实际字符，再判断是不是 Strict 拒绝了末尾量子。

按输入来源选择修复方式

修复不是把 Strict() 删除就结束。要先判断数据的生产方是否遵守同一套编码约定：

如果必须兼容旧系统，可以在边界层记录原始输入、选择的编码对象和错误位置，再由明确的兼容策略决定是否接受；业务层不要悄悄把所有输入降级为普通解码。这样既保留互操作性，也不会让坏数据继续进入签名、缓存键或持久化字段。

常见问题

Strict 会拒绝所有带换行的 Base64 吗？

不会。官方实现仍会忽略 CR 和 LF；真正需要单独检查的是普通空格、制表符、错误字母表以及末尾填充位。

CorruptInputError 的位置可以直接当作字符下标吗？

它表示解码器发现输入问题的位置，适合定位原始字节流。若输入来自多字节文本或经过转义，应先保留原始字节，再把位置映射到业务字段，不能直接按中文字符数换算。

没有等号的字符串应该关闭 Strict 吗？

先确认协议是否使用 Raw Base64。若确实无填充，应选择对应 Raw 编码；若协议规定标准填充，关闭 Strict 只会掩盖发送端生成不规范数据的问题。