直接用base64.stdencoding.encodetostring即可，但必须传[]byte而非string，否则编译失败；解码前需strings.trimspace清洗空白符并严格匹配编码器（stdencoding用于http/json，urlencoding用于url/jwt），大文件须用newencoder/newdecoder流式处理且调用close()。
直接用 base64.StdEncoding.EncodeToString 就行，但必须传 []byte，不是 string；传错类型会编译失败，不是运行时报错。
EncodeToString 为什么总报编译错误？
因为 Go 类型严格：base64.StdEncoding.EncodeToString 只接受 []byte，不接受 string。写成 base64.StdEncoding.EncodeToString("hello") 会直接编译失败。
- 正确写法是
base64.StdEncoding.EncodeToString([]byte("hello")) - 中文、emoji、二进制头（如
\xff\xfe）都 OK，[]byte是原始字节视图，不依赖 UTF-8 解释 - 如果数据来自
json.Marshal或io.ReadAll，务必先检查err和len(data) > 0；空切片返回空字符串""，容易被当成“成功”掩盖逻辑错误 - 别对已编码结果再做
string(b)强转——EncodeToString输出本身就是合法 ASCII 字符串，可直接用
DecodeString 总报 illegal base64 data 怎么快速修？
这不是数据损坏，而是格式校验失败：长度非 4 倍数、含空白符、编码器不匹配、填充位置非法。
- 第一步：用
strings.TrimSpace(input)清首尾空白（\n、\r、\t、空格），解决约 70% 的线上报错 - 第二步：确认编码/解码器是否配套——前端用
btoa()→ 后端必须用base64.StdEncoding；前端用Buffer.from().toString('base64url')→ 后端必须用base64.URLEncoding - 第三步：若来源不可靠（如用户粘贴、表单输入），加一层清洗：
clean := strings.Map(func(r rune) rune { if unicode.IsSpace(r) { return -1 }; return r }, input) - 长度不是 4 的倍数？仅对
StdEncoding场景补=：for len(clean)%4 != 0 { clean += "=" }
URL 安全场景该用哪个编码器？
标准 Base64 的 + 和 / 在 URL 查询参数里会被当空格或路径分隔符，= 在某些网关里可能被截断。不能靠 strings.ReplaceAll 粗暴替换。
- 必须用
base64.URLEncoding：它用-替代+，_替代/，默认省略填充= - JWT payload 等明确要求“无填充”的场景，得用
base64.RawURLEncoding，否则解码会报错 - 混用必炸：用
URLEncoding编，却用StdEncoding解，立刻触发illegal base64 data -
URLEncoding.DecodeString能容忍缺失的=，但不接受空格、中文、换行——仍需TrimSpace
大文件编解码为什么不推荐 EncodeToString？
EncodeToString 和 DecodeString 都会分配新内存，对大文件（>1MB）反复操作容易触发 GC 压力，且无法设限防恶意输入。
- 优先用流式处理：
base64.NewEncoder/base64.NewDecoder，配合io.Copy或自定义缓冲区 - 使用后必须调
Close()，否则可能漏写最后几个字节 - HTTP 服务中对请求体做 base64 解码，建议设上限：
if len(body) > 10*1024*1024 { return ErrTooLarge } - 若只是中转或透传，可用
Encode(dst, src)手动管理dst，长度至少为base64.StdEncoding.EncodedLen(len(src))
最容易被忽略的是：解码前没清洗、编码器没配对、大文件没流式处理。这三个点踩中任意一个，线上就容易出 illegal base64 data 或内存暴涨。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
