base64.StdEncoding.EncodeToString只接受[]byte，不接受string或nil切片；传"hello"会编译失败，必须写[]byte("hello")；解码前需strings.TrimSpace清洗并匹配编码器，URL场景须用URLEncoding。
base64.StdEncoding.EncodeToString 传什么、不传什么
它只接受 []byte，不接受 nil 切片，也不接受 string 类型——直接写 base64.StdEncoding.EncodeToString("hello") 会编译失败。必须显式转成字节切片：[]byte("hello")。
常见误操作：
- 传入未初始化的
var data []byte（值为nil），运行时 panic - 对含非 UTF-8 字节的数据（如 GBK 编码的文件头）直接
[]byte(s)，解码端用string(decoded)可能乱码 - 原始数据含
\x00等控制字符，编码结果合法，但后续塞进 JSON 可能被某些解析器截断
稳妥做法：明确原始数据意图，若来自文件或网络流，保持原始 []byte；若来自用户输入字符串，确认其编码格式再处理。
解码总报 illegal base64 data at input byte X 怎么定位
这个错误信息没说清哪错了，实际原因很琐碎，得一个个排除：
- 输入长度不是 4 的倍数：前端用
btoa()编码后没补足位数，或手动拼接时漏了填充 - 编码器和解码器不匹配：用
base64.URLEncoding编的，却用base64.StdEncoding.DecodeString解 - 字符串带不可见字符：从
粘贴、JSON 字段里读出的值末尾有\n或空格 - 填充符
=被意外删了：尤其在 URL 场景下有人觉得“多余”，strings.TrimRight(s, "=")后直接解码必崩
建议统一加清洗：s = strings.TrimSpace(s)，再选对编码器。不确定是否含填充？可先试 base64.RawStdEncoding.DecodeString(s)（它忽略 =）。
URL 和 JWT 场景必须用 base64.URLEncoding
标准 Base64 的 + 和 / 在 URL 查询参数、JWT header/payload、文件名里都会出问题：+ 被当空格，/ 被当路径分隔，= 在 query string 中可能被截断。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
base64.URLEncoding 不是简单替换字符，它是独立编码器：
- 用
-替代+，_替代/ - 默认无填充（不加
=），更紧凑 - 解码时容忍缺失的
=，但不接受空格、换行、中文等非法字符
关键点：编码和解码必须配套使用。混用 StdEncoding 和 URLEncoding 必报错，且错误信息一样，容易误判。
大文件别碰 EncodeToString，改用流式 NewEncoder
一个 50MB 的图片，Base64 编码后约 67MB 字符串，EncodeToString 会一次性分配这块内存；再解码又要分配 50MB 原始字节缓冲区——瞬时内存翻倍，GC 压力陡增。
正确姿势是流式处理：
- 编码：用
base64.NewEncoder(enc, writer)包装目标io.Writer（如bytes.Buffer或文件句柄），再io.Copy(encoder, srcReader) - 解码：用
base64.NewDecoder(enc, reader)包装输入源（如strings.NewReader(encoded)），再io.Copy(dstWriter, decoder) - 记得调用
encoder.Close()，否则末尾填充可能不写入
流式不攒整块内存，适合 HTTP body 中转、日志透传、文件嵌入等真实生产场景。真正要复用缓冲区做极致优化时，才考虑 Encode(dst, src) 手动管理长度——前提是你知道 enc.EncodedLen(len(src))。
