Base64编码用EncodeToString最直接，需防nil切片和空数据返回""；解码用DecodeString并严格校验错误，注意URL安全变体与填充差异；大文件应使用NewEncoder/NewDecoder流式处理，Close不可省；URLEncoding与RawURLEncoding不兼容，跨语言需统一填充约定。
Base64编码：用EncodeToString最直接
对一段字节数据做标准Base64编码，encoding/base64包里最常用的是EncodeToString函数。它接收[]byte，返回string，无需手动处理缓冲区。
常见错误是传入nil切片或未检查原始数据是否为空——这不会panic，但会返回空字符串""，容易被当成成功结果掩盖逻辑问题。
- 如果原始数据来自
json.Marshal或io.ReadAll，务必先判断err和len(data) == 0 - 中文、emoji等UTF-8字符需先转为
[]byte再编码，不能直接对string调用EncodeToString（虽然Go允许，但语义上应明确字节意图） - 标准编码使用
base64.StdEncoding；URL安全场景改用base64.URLEncoding，二者编码结果不兼容
Base64解码：用DecodeString并严格校验错误
DecodeString看似简单，但实际出错率远高于编码。典型错误信息如illegal base64 data at input byte X，往往因为输入含空白符、换行、或用了错误的编码变体（比如前端传了URL-safe编码，后端却用StdEncoding解）。
- 解码前建议用
strings.TrimSpace清理首尾空格和换行 - 不要忽略返回的
error——即使只做日志，也要区分base64.CorruptInputError和io.ErrUnexpectedEOF，后者可能表示截断传输 - 若输入来自HTTP请求参数或JSON字段，注意URL编码可能已对
+和/做了转义，需先url.QueryUnescape再解码
流式编解码：避免内存拷贝用NewEncoder/NewDecoder
处理大文件或HTTP响应体时，把整个内容读进内存再编解码既慢又占资源。这时应使用base64.NewEncoder或base64.NewDecoder包装io.Writer/io.Reader。
立即学习“go语言免费学习笔记（深入）”；
关键点在于：编码器写入目标io.Writer后，必须显式调用Close()，否则末尾2–3个字节可能丢失（Base64按3字节分组，不满时需补=，Close负责输出剩余填充）。
-
Encoder写入过程中不会报错，所有错误都延迟到Close()时返回 -
Decoder对非法输入默认静默跳过无效字符（如空格），若需严格模式，得自己预处理或用RawStdEncoding配合手动校验 - HTTP上传场景中，可将
*multipart.Part直接传给base64.NewDecoder，实现边接收边解码
自定义编码字符集：小心URLEncoding和RawStdEncoding的区别
标准Base64用+和/，但在URL或文件名中不安全。Go提供了base64.URLEncoding（用-和_替代），但它仍保留填充符=；真正无填充的是base64.RawURLEncoding。
混淆这两者会导致解码失败：比如用RawURLEncoding编码的字符串含-_但无=，若用URLEncoding解，会在末尾补=导致长度错误。
- 前后端约定必须明确指定是
URLEncoding还是RawURLEncoding -
RawStdEncoding去掉=但保留+/，极少用，除非对接某些遗留协议 - 验证编码是否合规：可用
base64.Encoding.WithPadding(base64.NoPadding)构造，但注意它不改变字符映射，仅控制填充行为
Base64本身不加密，只是编码；真正需要保密时，别只依赖它。另外，不同语言对填充的容忍度差异很大——Python的base64.urlsafe_b64decode自动补=，而Go默认不补，这点在跨语言联调时最容易卡住。
