EncodeToString 不适用于高并发场景，因其每次调用均分配新字符串，加剧 GC 压力；流式编码必须显式 Close() 否则丢失末尾字节；URLEncoding 与 RawURLEncoding 填充规则不同，错用导致解码失败。
为什么 EncodeToString 不能用于高并发场景
因为 EncodeToString 每次都分配新字符串，对高频调用（如每秒数千次 JWT 签名）会显著抬高 GC 压力。它内部调用 Encode + string()，无法复用底层缓冲区。
常见错误是把 base64.StdEncoding.EncodeToString([]byte("foo")) 当作“轻量操作”直接嵌在 HTTP handler 里——实际每请求都触发一次堆分配，压测时 GC pause 明显上升。
- 小数据（
- 中等数据（1–100 KB）建议预分配
[]byte缓冲区，用Encode替代 - 大文件或流式场景必须用
NewEncoder+io.Copy，否则内存爆掉
如何安全复用 []byte 缓冲区做 Base64 编码
标准库不提供全局缓冲池，但你可以自己控制：用 base64.StdEncoding.EncodedLen(len(src)) 预估目标长度，再传入已分配的 []byte。
关键点：别用 make([]byte, base64.StdEncoding.EncodedLen(len(src))) 后直接传给 Encode —— 它只写入实际需要的字节数，返回值才是有效切片长度。
立即学习“go语言免费学习笔记（深入）”；
- 正确写法：
n := base64.StdEncoding.Encode(dst, src); encoded := dst[:n] - 如果
dst不够长，Encode会 panic；务必确保容量足够 -
dst可来自sync.Pool，但注意 Pool 的 Get/ Put 成本是否划算（通常 >1 KB 才值得） - 别对
nil切片调用Encode，它不会 panic，但返回 0 —— 结果是空切片，容易被误判为成功
流式编码必须 Close()，否则末尾字节丢失
用 base64.NewEncoder 处理大文件或 HTTP body 时，Write 只刷部分数据，剩余 1–3 字节卡在内部缓冲区。不调 Close() 就等于丢数据。
典型崩点：日志文件导出成 Base64 后解码失败，查半天发现最后几个字符总是少 —— 八成没 Close()。
- 稳妥组合：
io.Copy(enc, src)，它会在复制结束后自动调enc.Close() - 手动管理时，
enc.Close()必须显式调用，且检查返回 error：if err := enc.Close(); err != nil { /* handle */ } - 别把
enc.Write()和enc.Close()放同一个 defer —— 中间 panic 会导致 Close 跳过 - 编码器本身不持有 src/dst 的所有权，
src.Close()和dst.Close()仍需你负责
URLEncoding 和 RawURLEncoding 的选择陷阱
URL 场景下用错编码器是最常见的 runtime 错误来源。base64.URLEncoding 仍带 = 填充，而 base64.RawURLEncoding 才真正无填充 —— 两者解码行为也不同。
JWT payload 或查询参数里看到 aGVsbG8= 是合法的，但若对方协议明确要求 “no padding”，就必须用 RawURLEncoding，否则解码报 illegal base64 data at input byte X。
-
URLEncoding：替换+→-、/→_，保留=填充 -
RawURLEncoding：同样替换符号，且完全省略=，解码时自动补足 - 别对
URLEncoding结果再strings.TrimRight(s, "=")—— 解码端若没同步处理，就直接失败 - 前端用
btoa()生成的是 StdEncoding，后端若用URLEncoding.DecodeString必崩，必须匹配
缓冲区复用不是银弹，真正容易被忽略的是：编码器选型和输入清洗必须前置 —— 无论你多 careful 地复用 []byte，只要传进一个含换行的字符串或错配的编码方案，DecodeString 依然会 panic。
