EncodeToString 必须传 []byte，不能传 string；解码报错优先检查长度、空白符和编码器匹配；大文件须用流式处理；JWT 应用需用 RawURLEncoding 无填充编码。
用 EncodeToString 编码前，必须传 []byte，不是 string
Go 的 encoding/base64 所有编码函数都只认字节切片，不接受 string 类型——这不是设计疏忽，而是语言层面对“字符串不可变”和“字节操作需显式语义”的坚持。直接传 "hello" 会编译失败：cannot use "hello" (untyped string constant) as []byte value in argument to base64.StdEncoding.EncodeToString。
- 正确做法：显式转成
[]byte("hello")，哪怕内容是纯 ASCII 或中文（UTF-8 字节序列） - 别依赖 “Go 有时能隐式转换” —— 这里绝不允许
- 如果原始数据来自
json.Marshal、io.ReadAll或 HTTP body，记得先检查err和len(data) > 0；空切片会返回空字符串""，容易被当成成功掩盖逻辑错误
解码总报 illegal base64 data at input byte X？先看这三件事
这个错误几乎从不表示数据真坏了，而是输入没过 Base64 的“形式审查”：长度非 4 倍数、含空格/\n、用了错的编码器、或填充符位置非法。JS 的 btoa() 输出常带换行，用户粘贴的 Base64 更可能混入空格或制表符。
- 第一步：用
strings.TrimSpace清首尾空白 —— 能解决 70% 的线上报错 - 第二步：确认编码/解码器匹配 —— 前端用
btoa()→ 后端必须用base64.StdEncoding；前端用Buffer.from().toString('base64url')→ 后端必须用base64.URLEncoding或base64.RawURLEncoding - 第三步：若不确定是否带填充（比如对接嵌入式设备），优先试
base64.RawStdEncoding.DecodeString—— 它完全忽略=，但字符集仍是+/，不等于 URL 安全
大文件别用 EncodeToString，流式处理必须调 Close()
一个 50MB 的二进制文件，Base64 编码后约 66MB 字符串，再解码又要分配 50MB 切片 —— 瞬时内存翻倍，GC 压力陡增，还可能 OOM。流式处理不是“高级技巧”，而是生产环境的底线要求。
- 编码用
base64.NewEncoder(enc, writer)，写完必须显式enc.Close()—— 否则最后 1–3 字节卡在缓冲区，输出缺字符，解码必炸 - 更稳妥写法：用
io.Copy(encoder, reader)，它内部会自动调Close()（只要writer实现了io.Closer） - 解码同理：
base64.NewDecoder包裹io.Reader，io.Copy写入目标文件即可，无需手动 Close
URLEncoding 和 RawURLEncoding 不是一回事，JWT 场景要盯紧填充
很多人以为 base64.URLEncoding 就是“无填充的 URL 安全版”，其实它默认仍会加 =（只是把 +// 换成 -/_）。而 JWT 规范明确要求头部和载荷使用 *no-padding* 的 URL-safe Base64 —— 这时候该用 base64.RawURLEncoding。
立即学习“go语言免费学习笔记（深入）”；
-
base64.URLEncoding.EncodeToString([]byte("hi"))→"aGk="（带=） -
base64.RawURLEncoding.EncodeToString([]byte("hi"))→"aGk"（无=，且用-_） - 解码时：
RawURLEncoding自动容忍缺失填充；但若你收到的是带=的 URL-safe 字符串（比如某些旧版 JWT 库），就得先strings.TrimRight(s, "=")再喂给它
最常被跳过的其实是“编码器选型”这件事：不是所有 Base64 都能互相解，也不是所有 = 都该被信任。一次编解码失败，八成问题出在两端没对齐编码规则，而不是数据本身。
