base64.StdEncoding.EncodeToString 是标准 Base64 编码函数，需传入 []byte 输入，自动处理填充和分块，输出 RFC 4648 兼容字符串，适用于 HTTP、JSON 等场景。
用 base64.StdEncoding.EncodeToString 编码字符串最直接
想把一段文本或字节转成 Base64 字符串？别绕弯，base64.StdEncoding.EncodeToString 就是你要找的函数。它自动处理分块、填充（=），输出符合 RFC 4648 的标准格式。
- 输入必须是
[]byte，不是string—— 直接传"hello"会编译失败，得写成[]byte("hello") - 它不接受
nil切片，否则运行时 panic - 输出不含换行符，也不做 URL 转义，适合 HTTP body、JSON 字段、日志调试等场景
- 如果原始数据含中文、emoji 等 UTF-8 多字节字符，没问题，因为
[]byte天然兼容
示例：base64.StdEncoding.EncodeToString([]byte("Hello, 世界")) → SGVsbG8sIOS4lueVjA==
解码必须检查 err，且注意编码器匹配
base64.StdEncoding.DecodeString 不会“尽力而为”，只要输入稍有不合规，就立刻返回错误，比如 illegal base64 data at input byte 4。这不是数据坏了，大概率是编码/解码器没对上，或者字符串混进了看不见的东西。
- 常见错误现象：前端用
btoa()编码后发来，后端用URLEncoding解，报错；或从 JSON 字段读出的字符串末尾带\n，没清洗就解码 - 务必先调
strings.TrimSpace去首尾空白（\n、\r、\t、空格） - 确认编码方式：
btoa()对应StdEncoding，Buffer.from().toString('base64url')才对应URLEncoding - 若不确定是否含填充，优先试
base64.RawStdEncoding.DecodeString（它完全忽略=）
示例：decoded, err := base64.StdEncoding.DecodeString(strings.TrimSpace(input))，err != nil 时不能跳过
立即学习“go语言免费学习笔记（深入）”；
URL 安全场景必须用 base64.URLEncoding
标准 Base64 的 + 和 / 在 URL、文件名、JWT 中会出问题：+ 被当空格，/ 被当路径分隔符，= 在查询参数里也可能被截断。这时候不能靠手动替换，得用 Go 原生支持的 base64.URLEncoding。
- 它用
-替代+，_替代/，默认省略填充=，更紧凑也更安全 - 编码和解码必须配套使用：用
URLEncoding编，就得用URLEncoding解，混用必报illegal base64 data - 它解码时能容忍缺失的
=，但不接受非法字符（如空格、中文）——仍需TrimSpace - JWT header/payload、API 查询参数、短链 token 都属于这个场景
示例：base64.URLEncoding.EncodeToString([]byte("user:pass")) → dXNlcjpwYXNz（无 =，无 +//）
大文件别用 EncodeToString，改用流式 base64.NewEncoder
一个 100MB 的二进制文件，Base64 编码后约 133MB 字符串，再解码又要分配一块原始大小的 []byte，瞬时内存翻倍，GC 压力陡增。这不是函数不支持，是内存模型决定的硬伤。
- 正确做法：用
base64.NewEncoder包裹io.Writer（如文件、HTTP response body），然后io.Copy流式写入 - 关键细节：
Close()必须显式调用，否则末尾 1–3 字节可能卡在缓冲区没写出，导致解码失败 -
io.Copy是更稳妥的选择，因为它内部会自动调用Closer.Close()（只要目标实现了io.Closer） - 解码同理：用
base64.NewDecoder包裹io.Reader，再io.Copy写出
示例：enc := base64.NewEncoder(base64.StdEncoding, dst); io.Copy(enc, src); enc.Close()
最容易被忽略的点是：解码前不清洗空白、编码解码器混用、大文件硬塞进内存、流式处理漏掉 Close()。这些都不是“高级技巧”，而是上线前必须卡死的边界条件。
