应根据使用场景选择编码器：http body等用stdencoding，url/jwt等用urlencoding，无填充要求则用rawurlencoding；传nil切片会静默返回空字符串，需提前判空；解码前须trimspace并严格匹配编码器，否则报illegal base64 data。
别用 base64.StdEncoding 往 URL 里塞数据——它生成的 + 和 / 会被服务端当空格或路径分隔符吃掉，解码必然失败。
怎么选 StdEncoding 还是 URLEncoding
看数据往哪走：
- HTTP body、JSON 字段、文件内容、数据库存储 → 用
base64.StdEncoding - URL 查询参数、JWT header/payload、Cookie 值、文件名 → 必须用
base64.URLEncoding - 对方明确要求“无填充”（no padding），比如某些嵌入式协议或旧版 JWT 实现 → 用
base64.RawURLEncoding，否则DecodeString会报illegal base64 data at input byte X
硬把 StdEncoding 结果用 strings.ReplaceAll 换 + 和 / 是错的：你没处理填充符 = 的逻辑，且解码端若没同步替换，就直接崩。
EncodeToString 返回空字符串？八成是输入为 nil
base64.StdEncoding.EncodeToString 和 URLEncoding.EncodeToString 都不会 panic，但传 nil 切片进去就静默返回空字符串 ""，极易被当成“编码成功”误导后续逻辑。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 检查是否为
nil：if data == nil { /* 处理空输入 */ }，注意var data []byte是nil，而data := make([]byte, 0)才是空切片 - 从 JSON 解析出来的字段（如
json.RawMessage）可能为nil，尤其字段未提供时 - 别对字符串盲目转字节：
[]byte(s)若s含非法 UTF-8（如 GBK 文件头），解码端用string(decoded)会乱码；应明确原始编码意图，必要时保留原始[]byte
解码失败报 illegal base64 data at input byte X 怎么查
这不是 Go 实现有问题，而是输入本身不合规。常见原因：
- 字符串被截断：日志截断、DB 字段长度限制（比如 VARCHAR(255) 存了 256 字节 base64）、HTTP header 被代理截断
- 含不可见字符：开头/结尾有换行、空格、
\t，解码前务必strings.TrimSpace(s) - 编解码不匹配：用
StdEncoding.DecodeString去解URLEncoding.EncodeToString的结果，必报错 - 长度非 4 的倍数：标准 base64 要求补
=，但URLEncoding允许省略；别手动补=，否则解码失败 - JSON 解析错误：字段本该是字符串却写了数字（
"data": 123），json.Unmarshal会静默赋值为空字符串，再解码就崩
高频调用时内存和性能怎么控
每次调用 EncodeToString 或 DecodeString 都分配新内存，HTTP 中间件、日志脱敏等场景 GC 压力明显。
- 用预分配切片替代字符串操作：
dst := make([]byte, base64.StdEncoding.EncodedLen(len(src))); base64.StdEncoding.Encode(dst, src) - 解码同理：
dst := make([]byte, base64.StdEncoding.DecodedLen(len(src))); n, err := base64.StdEncoding.Decode(dst, src) - 如果反复编解码同类数据，考虑复用
bytes.Buffer或 sync.Pool 管理目标切片
真正容易被忽略的是：URL 场景下，URLEncoding 不仅改了字符，还默认跳过填充——这意味着你不能假设所有 base64 字符串都以 = 结尾；而解码端若用错编码器，连第一个字节都过不去。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
