base64编码选stdencoding还是urlencoding取决于使用场景：web api、jwt、文件名用urlencoding（避免+ /问题），邮件、mime、日志用stdencoding；解码失败多因编解码器不匹配或含空白字符，需trimspace并确认编码源；大文件应使用newencoder/newdecoder流式处理防内存爆炸。
Base64编码用base64.StdEncoding.EncodeToString()还是base64.URLEncoding.EncodeToString()
取决于你传给谁用。标准编码含 + 和 /，URL/文件名里会出问题；URL安全编码用 - 和 _ 替代，不需额外转义。
常见错误：把用户上传的 Base64 图片字符串直接存数据库或拼进 URL，结果遇到 + 被当空格、/ 被当路径分隔符——后端解码失败，报 illegal base64 data。
- Web API 传参、JWT payload、文件名嵌入 → 用
base64.URLEncoding - 邮件 MIME、传统协议字段、本地日志调试 → 用
base64.StdEncoding - 别混用：编码用 Std，解码用 URL → 必然失败
解码时为什么总报illegal base64 data at input byte X
不是数据坏了，大概率是编码格式和解码器不匹配，或者字符串带了不可见字符。
典型场景：前端用 btoa() 编码后发到 Go 后端，但没处理换行或空格；或者从 JSON 字段读出的字符串末尾有 \n。
立即学习“go语言免费学习笔记（深入）”；
- 先用
strings.TrimSpace()清掉首尾空白 - 确认编码方式：JS 的
btoa()对应 Go 的StdEncoding，Buffer.from(...).toString('base64url')才对应URLEncoding - 长度必须是 4 的倍数，不足补
=；但URLEncoding默认忽略填充，解码时设WithPadding(base64.NoPadding)更稳妥
base64.StdEncoding.DecodeString()和base64.RawStdEncoding.DecodeString()差在哪
就差一个填充（padding）校验。RawStdEncoding 完全不检查 =，适合处理省略填充的旧协议或嵌入式设备输出。
性能上没差别，但兼容性很关键：有些嵌入式固件、IoT 设备的 Base64 输出为了省字节，直接砍掉末尾的 =；用 StdEncoding 解就会报错。
- 对接外部系统前，先看文档是否注明 “no padding”
- 不确定时，优先试
RawStdEncoding；成功后再按需加校验逻辑 -
RawStdEncoding不等于URLEncoding：前者只是忽略=，仍用+//字符集
大文件 Base64 编解码要不要自己分块
要，但不是因为函数不支持——EncodeToString() 和 DecodeString() 本身能处理任意长度字符串。问题是内存爆炸。
一个 100MB 二进制文件 Base64 编码后约 133MB 字符串，Go 里字符串不可变，解码时还要再分配一块原始大小的 []byte，瞬时内存翻两倍以上，GC 压力陡增。
- 用
base64.NewEncoder()/NewDecoder()包裹io.Reader或io.Writer，流式处理 - 例如：读文件 →
base64.NewDecoder(..., file)→ 写入目标os.File，全程内存占用恒定 - 注意：流式解码不校验末尾填充，若源数据可能缺
=，得自己补或换RawStdEncoding
Base64 看似简单，真正卡住人的永远是边界：编码变体、填充策略、隐式空白、流控粒度。别信“一行搞定”，先看清楚数据从哪来、到哪去、中间有没有人动过它。
