base64.StdEncoding.EncodeToString 返回空字符串是因为传入了 nil 或零长切片；需显式判空，区分 var b []byte（nil）与 b := make([]byte, 0)；URL 场景须用 URLEncoding 避免字符冲突；解码失败多因非法字符、空白符或编解码不匹配；高频调用应复用缓冲区以减少 GC。
base64.StdEncoding.EncodeToString 为什么返回空字符串？
不是编码失败，而是传入了 nil 切片或长度为 0 的切片——EncodeToString 本身不会报错，但结果是空字符串，容易误判为逻辑 bug。
- 确认输入是否为
nil：if data == nil { /* 处理空数据 */ } - 避免直接对未初始化的 slice 使用：
var data []byte是nil，不是空切片；要用data := make([]byte, 0)或字面量[]byte{} - HTTP body、JSON 字段解析后可能为
nil，尤其在结构体字段未设置时（如使用json.RawMessage）
URL 安全 Base64 编码要用 base64.URLEncoding，别硬换字符
标准 Base64 的 + 和 / 在 URL 路径或查询参数中会被服务端截断或转义，导致解码失败；= 填充符也可能被某些代理丢弃。
- 用
base64.URLEncoding.EncodeToString(data)，它用-和_替代+//，且默认不强制填充（可选） - 解码时必须配对使用
base64.URLEncoding.DecodeString(s)，混用StdEncoding会报illegal base64 data - 如果接收方是 JS 的
btoa()，注意它只支持标准编码，此时需统一用StdEncoding+ URL 编码包裹（不推荐，增加层级）
base64 解码失败常见错误：illegal base64 data at input byte X
这个错误几乎都来自输入字符串含非法字符、长度不对，或编码/解码方式不匹配，而不是 Go 实现有问题。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 检查字符串是否被意外截断（比如日志截断、数据库字段长度限制、HTTP header 截断）
- 确认是否带了空白符：
strings.TrimSpace(s)再解码，否则开头/结尾的换行或空格会触发错误 - 长度必须是 4 的倍数；不足时补
=是标准行为，但URLEncoding允许省略填充，所以不要手动补= - 从 JSON 解析出来的 base64 字符串，如果原始字段是数字或布尔值（比如误写
"data": 123），json.Unmarshal会静默赋值为空字符串，解码时就崩
性能敏感场景下，避免反复分配 —— 复用 bytes.Buffer 或预分配目标切片
EncodeToString 内部会新建 string，DecodeString 会新建 []byte，高频调用时 GC 压力明显；尤其在 HTTP 中间件、日志脱敏等场景。
立即学习“go语言免费学习笔记（深入）”；
- 用
Encode+ 预分配切片代替EncodeToString：dst := make([]byte, base64.StdEncoding.EncodedLen(len(src))); base64.StdEncoding.Encode(dst, src) - 解码同理：
dst := make([]byte, base64.StdEncoding.DecodedLen(len(src))); n, _ := base64.StdEncoding.Decode(dst, src)，再用dst[:n] - 若需多次编码同一类型数据（如 token payload），把
bytes.Buffer提到循环外，用buf.Reset()复用
Base64 不是加密，只是编码；它的边界模糊点在于：URL 安全性、填充处理、空值容忍度——这些地方不细看文档，很容易在线上跑几天才暴露问题。
