Go中Base64编解码必须显式指定编码器：StdEncoding用于HTTP/JSON等标准场景（含+、/、=），URLEncoding用于JWT/URL参数（用-、_替代+、/，省略=），混用或未TrimSpace将导致illegal base64 data错误。
别用 base64.EncodeToString 或 base64.DecodeString 这种不存在的包级函数——Go 的 encoding/base64 没有全局快捷入口，必须显式指定编码器。
StdEncoding 用于 HTTP body、JSON、日志等纯文本场景
标准 Base64 用 + 和 /，末尾带 = 填充，适合不经过 URL 解析路径的数据传输。
常见错误现象：illegal base64 data at input byte X，八成是用了 URLEncoding.DecodeString 去解前端 btoa() 生成的字符串（它对应 StdEncoding）。
- 编码：用
base64.StdEncoding.EncodeToString([]byte("hello"))→aGVsbG8= - 解码：必须配对用
base64.StdEncoding.DecodeString(s)，不能省略接收器 - 输入为
nil []byte时静默返回空字符串""，不是 panic，但极易被误判为“成功” - 若原始数据含非法 UTF-8（如 GBK 文件头），解码后别直接
string(decoded)，先用utf8.Valid(decoded)判断
URLEncoding 才是 JWT、查询参数、Cookie 的正确选择
URL 安全变体把 + 换成 -、/ 换成 _，默认省略 =，避免被代理或浏览器当空格/路径分隔符吃掉。
立即学习“go语言免费学习笔记（深入）”；
硬用 strings.ReplaceAll 把 StdEncoding 结果的 +// 替换掉是错的：填充逻辑没同步处理，且解码端若没做同样替换就直接崩。
- 编码：用
base64.URLEncoding.EncodeToString([]byte("user:pass"))→dXNlcjpwYXNz（无=，无+//） - 解码：必须用
base64.URLEncoding.DecodeString(strings.TrimSpace(input))，TrimSpace不可省——开头换行、结尾空格都会导致失败 - 长度非 4 的倍数？
URLEncoding能容忍，但StdEncoding严格要求；别手动补=，否则解码失败 - 若对方明确要求“无填充”，比如某些嵌入式协议，得用
base64.RawURLEncoding，否则解码必报错
解码失败时怎么快速定位 illegal base64 data 错误
这不是 Go 实现有 bug，而是输入本身不合规。最常被跳过的三件事：
- 没调
strings.TrimSpace：日志截断、HTTP header 被代理吞掉末尾、JSON 字段带\n都会导致首尾不可见字符存在 - 编解码器不匹配：前端用
Buffer.from().toString('base64url')，后端却用StdEncoding.DecodeString - 数据库字段或日志存储时被截断：VARCHAR(255) 存了 256 字节 base64，最后几个字符丢了，长度不再是 4 的倍数
调试建议：先打印 len(input) 和 fmt.Printf("%q", input) 看是否含 \n、\r 或多余 =；再确认来源是 btoa 还是 base64url 编码。
大文件或批量处理必须用流式接口
EncodeToString 和 DecodeString 会一次性分配约 4/3 倍内存，几 MB 就可能触发 GC 压力；流式处理内存恒定在 KB 级。
- 编码大文件：用
base64.NewEncoder(base64.StdEncoding, dstWriter)，写完必须显式enc.Close()，否则末尾字节丢失 - 解码字符串流：用
base64.NewDecoder(base64.URLEncoding, strings.NewReader(s))，注意输入必须是io.Reader，不能直接传string - 批量解码大量日志中的 base64 字符串？复用
NewDecoder包装每个strings.NewReader(s)，比反复调DecodeString更省 GC
最容易被忽略的点：流式编码后不 Close()，或者把 Write() 和 Close() 都 defer，panic 发生时 Close() 就不会执行，输出永远少几个字符。
