Go标准库encoding/base64提供StdEncoding、URLEncoding和RawURLEncoding三种编码器：StdEncoding用于纯二进制场景，URLEncoding适配URL/JWT（-代替+、_代替/），RawURLEncoding无填充；编解码需注意输入校验、空格截断、编码匹配及内存优化。
Go 语言里 base64 编解码不用额外装包，标准库 encoding/base64 就够用，但默认编码器不处理 URL 安全场景，也容易在边界上出错——比如空字节、非 UTF-8 字符、换行截断。
用 base64.StdEncoding 还是 base64.URLEncoding？
选哪个取决于你往哪传数据：
-
StdEncoding生成含+和/的字符串，适合 HTTP body、文件内容等纯二进制上下文 -
URLEncoding把+换成-、/换成_，不加换行，能直接塞进 URL 查询参数或 JWT header - 如果对方系统明确要求“无填充”（no padding），得用
base64.RawURLEncoding，否则解码会报illegal base64 data at input byte X
base64.StdEncoding.EncodeToString() 的常见崩点
看着简单，但实际调用时最容易栽在输入上：
- 传
nil切片进去不会 panic，但返回空字符串，容易被当成“成功编码”误判 - 如果原始字节含控制字符（比如
\x00），编码结果完全合法，但后续 JSON 序列化可能被截断（某些解析器对 NUL 敏感） - 别对字符串直接
[]byte(s)后编码——如果 s 含非 UTF-8 字节（如 GBK 文件头），解码端用string(b)可能乱码，应明确原始编码意图
安全写法示例：
立即学习“go语言免费学习笔记（深入）”；
data := []byte{0xff, 0xfe, 0x00, 0x01}
encoded := base64.StdEncoding.EncodeToString(data) // "//4AAYE="
解码时为什么总报 illegal base64 data？
错误信息本身没说清问题在哪，实际原因很琐碎：
- 输入字符串长度不是 4 的倍数（常见于手动拼接或前端 JS 的
btoa()结果没补足） - 用了
URLEncoding编码，却用StdEncoding解码（符号不匹配） - 字符串末尾有空格或换行（比如从 textarea 粘贴进来），
strings.TrimSpace()得自己加 - 填充符
=被意外删了（尤其在 URL 场景下有人觉得“多余”就 trim 掉）
稳妥解码建议：
s := strings.TrimSpace(input) decoded, err := base64.URLEncoding.DecodeString(s)
性能和内存：小数据别怕，大数据要留意
EncodeToString() 和 DecodeString() 都会分配新内存，对大文件（>1MB）反复编解码容易触发 GC 压力：
- 如果只是中转或透传，优先用
Encode()/Decode()配合预分配的[]byte缓冲区 - HTTP 服务中对请求体做 base64 解码，建议设上限（如
if len(body) > 10*1024*1024 { return ErrTooLarge }），防止恶意长串耗尽内存 -
RawURLEncoding比URLEncoding快一丢丢（少检查填充），但差距通常可忽略
真正容易被跳过的点是：base64 不是加密，只是编码；它不提供保密性，也不校验完整性——如果你需要防篡改，得额外加 HMAC 或用 crypto/aes。
