base64.StdEncoding.EncodeToString是最常用编码入口，将字节切片转为标准Base64字符串（含+/=），适用于API返回、日志脱敏等；解码需检查error；大文件应使用NewEncoder并显式Close；JWT必须用URLEncoding或RawURLEncoding。
base64.StdEncoding.EncodeToString 是最常用的编码入口
直接把字节切片转成 base64 字符串，不需要手动管理缓冲区。它内部调用 Encode 并返回 string，适合大多数场景，比如 API 返回体、日志脱敏、简单 token 生成。
注意：它使用标准 Base64 字母表（A-Z a-z 0-9 + /），结尾用 = 填充。如果目标系统要求 URL 安全（比如 JWT header/payload），得换 base64.URLEncoding。
package main
import (
"encoding/base64"
"fmt"
)
func main() {
data := []byte("hello world")
encoded := base64.StdEncoding.EncodeToString(data)
fmt.Println(encoded) // aGVsbG8gd29ybGQ=
}
base64.StdEncoding.DecodeString 处理常见解码失败
解码失败时不会 panic，而是返回 error。典型错误包括：illegal base64 data at input byte X（含非法字符）、illegal base64 data at input byte X, input len Y（长度不满足 4 的倍数）。
实际使用中必须检查 error，不能假设输入一定合法。尤其当 base64 来自 HTTP 请求参数、前端表单或第三方接口时，容易混入空格、换行、多余等号或被截断。
立即学习“go语言免费学习笔记（深入）”；
- 先用
strings.TrimSpace清除首尾空白 - 避免直接对用户输入做 decode，应加
if err != nil分支处理 - 若需容忍填充缺失，可先补足
=（但要小心长度校验逻辑）
base64.NewEncoder 写入流时注意 flush
当处理大文件或需要写入 io.Writer（如 http.ResponseWriter、文件、网络连接）时，用 base64.NewEncoder 更省内存。但它不会自动 flush 编码缓冲区 —— 必须显式调用 Close()，否则末尾数据可能丢失。
常见错误是只写完就结束，没 close，导致最后几个字节没编码输出。例如：
encoder := base64.NewEncoder(base64.StdEncoding, w)
encoder.Write([]byte("hello")) // 这里不会立刻写出完整 base64
encoder.Close() // 必须调用，否则 "hello" 可能只输出部分字符
StdEncoding vs URLEncoding：别在 JWT 场景用错编码器
JWT header 和 payload 要求 URL 安全 Base64（RFC 4648 §5），即用 - 替代 +、_ 替代 /、省略填充 =。用 StdEncoding 编码后直接拼进 JWT，会导致签名验证失败。
对应关系：
-
base64.StdEncoding→ 用于通用文本编码（如邮件 MIME） -
base64.URLEncoding→ 用于 URL、文件名、JWT 等不允许+//的场景 -
base64.RawURLEncoding→ 同 URLEncoding，但彻底不加填充（更紧凑，推荐 JWT 使用）
混淆这三者是线上 JWT 解析失败的高频原因，尤其是从其他语言迁移过来的开发者容易忽略填充和字符替换差异。
