base64只是编码而非加密，不提供安全性；必须先判空防nil输入，严格匹配编码器，清洗空白符，并注意大文本性能优化。
base64 不是加密，只是编码。它不提供任何安全性，仅用于将二进制数据转为可传输的 ASCII 字符串。如果你在处理“敏感字符串”，必须先明确：Base64 编码后仍可被任意工具秒级还原，不能替代 AES、RSA 等真实加密手段。
EncodeToString 必须传 []byte，且不能传 nil
直接写 base64.StdEncoding.EncodeToString("hello") 会编译失败——Go 不允许隐式转换 string 到 []byte。
正确写法是 base64.StdEncoding.EncodeToString([]byte("hello"))。
但更关键的是：如果原始数据来自 JSON（如 json.RawMessage）、HTTP header 或数据库字段，可能为 nil 切片，此时 EncodeToString(nil) 会静默返回空字符串 ""，极易掩盖逻辑错误。
- 务必提前判空：
if data == nil { return "", errors.New("input is nil") } - 若原始字符串含非法 UTF-8（如 GBK 编码片段），
[]byte(s)会原样保留字节，解码端用string(decoded)可能显示 ，这不是 Base64 的问题，而是编码意图未对齐 - 敏感字符串若本就来自用户输入，建议先做业务校验（如长度、字符集），再编码，避免把脏数据一路 encode 进日志或传输链路
DecodeString 前必须清洗空白符并匹配编码器
报错 illegal base64 data at input byte X 几乎从不表示数据损坏，而是格式“硬性不合规”：首尾有空格/\n、中间有 tab、长度非 4 倍数、或用了错的编码器。
- 第一步：用
strings.TrimSpace(input)清首尾空白 —— 解决约 70% 的线上解码失败 - 第二步：若来源不可靠（如用户粘贴、表单提交），再加
clean := strings.Map(func(r rune) rune { if unicode.IsSpace(r) { return -1 }; return r }, input)删除所有空白符 - 第三步：确认编码器匹配 —— 前端用
btoa()→ 后端必须用base64.StdEncoding；前端用Buffer.from().toString('base64url')→ 后端必须用base64.URLEncoding；JWT payload 通常用base64.RawURLEncoding（无填充） - 别用
strings.ReplaceAll(s, " ", "+")这类粗暴替换去“修复” URL 场景输入 ——URLEncoding的字符集是-_，不是+/-/，补错字符+补错 = 直接失败
大文本或高频调用时内存和性能要盯紧
一个 10MB 的敏感字符串（比如一段密钥材料的 JSON 表示）经 Base64 编码后约 13.3MB 字符串，EncodeToString 和 DecodeString 每次都会分配新内存。在 HTTP 中间件、审计日志脱敏等高频场景，GC 压力会明显上升，甚至触发 OOM。
- 批量处理多个 Base64 字段时，优先用流式解码：
dec := base64.NewDecoder(base64.StdEncoding, strings.NewReader(s))，再配合io.ReadAll(dec)—— 内部缓冲复用，避免中间[]byte分配 - 若需反复编解码同一类数据（如 token payload），可预分配目标切片：
dst := make([]byte, base64.StdEncoding.EncodedLen(len(src)))，再用base64.StdEncoding.Encode(dst, src)避免字符串分配 - 流式编码必须显式调
enc.Close()—— 否则最后 1–3 字节卡在缓冲区，输出缺损，下游解码必炸；更稳妥写法是io.Copy(enc, reader)，它内部自动Close()（只要enc实现io.Closer）
真正棘手的点不在语法，而在边界：你永远不知道上游传来的 Base64 字符串是否被截断（DB VARCHAR 长度限制、代理截 header）、是否被二次 URL 解码过（+ 变空格）、是否混用了编码器变体。清洗 + 匹配 + 判空，这三步漏掉任何一环，线上就会出现看似随机实则必然的解码失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
