必须传[]byte而非string，否则编译失败；nil切片导致panic；解码前需TrimSpace、匹配编码器、大文件须流式处理。
直接用 base64.StdEncoding.EncodeToString，但必须传 []byte，不是 string —— 这是 90% 编译失败和运行时 panic 的根源。
为什么 EncodeToString 总是报错或 panic？
它不接受 string 类型，也不容忍 nil 切片：
- 写
base64.StdEncoding.EncodeToString("hello")→ 编译失败：cannot use "hello" as[]byte - 写
base64.StdEncoding.EncodeToString(nil)→ 运行时 panic：invalid memory address - 原始数据来自
json.Marshal或io.ReadAll？务必先检查err和len(data) > 0，空切片会返回""，容易掩盖逻辑错误
前端传来的 Base64 字符串解码总报 illegal base64 data at input byte X？
这个错误几乎从不表示数据损坏，而是格式“没过关”：
- 先调
strings.TrimSpace(input)—— 用户粘贴、textarea提交、HTTP header 换行都可能带\n、\r、空格 - 确认编码器匹配：
btoa()对应base64.StdEncoding；Buffer.from(...).toString('base64url')才对应base64.URLEncoding - 若对接嵌入式设备或旧系统，填充符
=可能被截断，优先试base64.RawStdEncoding.DecodeString(s)（忽略=，但字符集仍是+/）
URL、JWT、查询参数里该用哪个编码器？
标准 Base64 的 + 和 / 在 URL 中会被误解：+ 当空格，/ 当路径分隔，= 在 query string 里可能被截断。
立即学习“go语言免费学习笔记（深入）”；
别手动替换，用原生支持：
- 编码：用
base64.URLEncoding.EncodeToString([]byte("user:pass"))→ 输出dXNlcjpwYXNz（无+、/、=） - 解码：必须配套用
base64.URLEncoding.DecodeString(s)，混用必报错 - 注意：
URLEncoding解码时自动容忍缺失的=，但依然拒绝空格、中文、制表符等非法字符
大文件（>1MB）别碰 EncodeToString 和 DecodeString
一个 50MB 文件 Base64 编码后约 66MB 字符串，再解码又要分配 50MB 切片 —— 瞬时内存翻倍，GC 压力陡增，还可能 OOM。
正确做法是流式处理：
- 编码：用
base64.NewEncoder(enc, writer)包裹目标io.Writer，然后io.Copy(encoder, src)，最后别忘了encoder.Close()（否则末尾填充不写入） - 解码：用
base64.NewDecoder(enc, reader)包裹源io.Reader，再io.Copy(dst, decoder) - HTTP 服务中解析请求体前，建议加长度限制：
if len(body) > 10*1024*1024 { return ErrTooLarge }
真正容易被忽略的是：所有解码函数都不“容错”，DecodeString 不是尽力而为，而是严格校验。哪怕只多一个空格、少一个 =、错用编码器，就立刻返回 error —— 这不是 bug，是设计使然。清洗输入、匹配编码器、设好内存上限，这三件事漏掉任何一项，线上就等着收告警。
