Go 的 EncodeToString/DecodeString 在大数据量下易引发内存浪费和 GC 压力，应改用预分配缓冲的 Encode/Decode 或流式 NewEncoder/NewDecoder，并注意 RawURLEncoding 的长度校验与 Close 调用时机。
Go 的 EncodeToString 和 DecodeString 在小数据上没问题，但一旦处理 >100KB 的 Base64 字符串，内存分配会明显拖慢吞吐、触发 GC，甚至 OOM。关键不是“能不能用”，而是“在哪用、怎么配缓冲”。
为什么 EncodeToString/DecodeString 容易吃内存
这两个函数每次调用都分配新字符串或切片：编码时按 EncryptedLen 分配目标字符串空间，解码时按 DecodedLen 分配字节切片——而 DecodedLen 返回的是“最大可能长度”，不是实际长度，导致缓冲区浪费；更麻烦的是，它们不复用底层缓冲，高频调用（如 API 网关做日志脱敏）会让 GC 压力陡增。
-
base64.StdEncoding.EncodedLen(100_000)返回 133336，即每次编码都 new 一个 133KB 字符串 -
base64.StdEncoding.DecodedLen(133336)返回 100002（向上对齐），但真实解码结果可能只有 99998 字节，末尾 4 字节被零值填充 - 若输入是
json.RawMessage或 HTTP header 值，你还得额外strings.TrimSpace，又多一次字符串拷贝
预分配缓冲 + Encode/Decode 替代字符串操作
绕过字符串分配，直接操作预分配的 []byte，能省掉至少一次内存拷贝。适用于已知原始数据长度、且需反复编解码的场景（如 JWT payload 处理、数据库 BLOB 转换）。
- 编码：先调
base64.StdEncoding.EncodedLen(len(src))算出目标长度，dst := make([]byte, n)，再用base64.StdEncoding.Encode(dst, src) - 解码：先调
base64.StdEncoding.DecodedLen(len(src))预估最大长度，dst := make([]byte, n)，再用n, err := base64.StdEncoding.Decode(dst, src)—— 注意返回的n是真实写入长度，别直接string(dst)，要用string(dst[:n]) - 如果原始数据来自
io.ReadCloser（如http.Request.Body），别先ioutil.ReadAll再解码；改用base64.NewDecoder流式处理，避免两份大内存共存
流式编解码必须 Close()，否则丢数据
base64.NewEncoder 内部有 3 字节缓冲区，用于凑满 Base64 的 3→4 字节分组逻辑。不 Close()，最后不满 3 字节的 chunk 就卡在 buffer 里不输出，解码端拿到截断字符串，必然报 illegal base64 data at input byte X。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
defer enc.Close()包在函数开头 —— panic 时 defer 不执行，数据就丢了 - 正确写法：写完后立即
if err := enc.Close(); err != nil { /* handle */ } - 更省心：用
io.Copy(dst, base64.NewEncoder(enc, src))，io.Copy内部会自动调Close()（只要 writer 实现io.Closer） - 同理，
base64.NewDecoder不需要 Close，但它包装的 reader 若是os.File或net.Conn，仍需你自己关底层资源
RawURLEncoding 场景下无填充 ≠ 可跳过长度校验
用 base64.RawURLEncoding 编码时确实不加 =，但解码时它仍要求输入长度是 4 的倍数。如果前端 JS 的 btoa() 结果被中间层（如 Nginx、CDN）意外截断，或 DB 字段长度限制导致末尾字符丢失，DecodeString 依然会崩。
- 不要假设 “Raw 就不用管长度” ——
base64.RawURLEncoding.DecodeString("aGVs")成功，但base64.RawURLEncoding.DecodeString("aGV")直接 panic - 若来源不可控（如用户粘贴、第三方回调），解码前先检查
len(s)%4 == 0，不满足就拒绝或补足（仅限 StdEncoding 场景；Raw 类型补=会失败） - 真正安全的做法是：用
base64.RawURLEncoding.DecodeString前，先strings.TrimSpace，再确认长度合规，最后才解码 —— 少一步都可能在线上静默失败
