base64.StdEncoding.EncodeToString 是最常用的编码入口，需先将字符串转为 []byte；DecodeString 可能 panic，必须检查 error；URL 安全场景应使用 URLEncoding；大文件应避免 EncodeToString/DecodeString，改用 NewEncoder/NewDecoder 并注意 Close。
base64.StdEncoding.EncodeToString 是最常用的编码入口
Go 标准库的 encoding/base64 包不提供“一键编码字符串”的函数，必须先将字符串转为 []byte，再用编码器处理。常见错误是直接传字符串给 EncodeToString——它只接受字节切片。
正确做法：
- 用
[]byte("hello")转换原始字符串（UTF-8 安全） - 调用
base64.StdEncoding.EncodeToString()得到标准 Base64 字符串 - 注意：
StdEncoding使用+和/，适合 HTTP/JSON 场景；若需 URL 安全，改用URLEncoding
示例：
data := []byte("hello world")
encoded := base64.StdEncoding.EncodeToString(data) // "aGVsbG8gd29ybGQ="
base64.StdEncoding.DecodeString 可能 panic，必须检查 error
解码失败时，DecodeString 不返回空字符串或零值，而是返回 nil, error。忽略 error 会导致后续 panic（比如对 nil 切片做 range）。
典型错误场景：
立即学习“go语言免费学习笔记（深入）”；
- 输入含非法字符（如空格、换行、中文）
- 长度不是 4 的倍数（Base64 要求填充）
- 用了
URLEncoding编码却用StdEncoding解码
务必显式检查：
decoded, err := base64.StdEncoding.DecodeString("aGVsbG8gd29ybGQ=")
if err != nil {
log.Fatal(err) // 或返回错误
}
s := string(decoded) // "hello world"
URL 安全 Base64 需用 base64.URLEncoding，且不自动补等号
Web API 和 JWT 常用 URL 安全变体：用 - 替代 +，_ 替代 /，省略填充字符 =。Go 的 base64.URLEncoding 支持编码，但解码时对缺失 = 更宽容——它会自动补全。
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
不过仍要注意：
- 编码后字符串可能不含
=，但解码时无需手动补；URLEncoding.DecodeString内部已处理 - 若原始数据长度模 3 余 1，Base64 应补两个
=；余 2 则补一个；URLEncoding编码结果默认不带它们 - 不要混用：用
URLEncoding编码，就必须用它解码
示例：
s := base64.URLEncoding.EncodeToString([]byte("hi"))
// 可能输出 "aGk"（无 =），但 DecodeString("aGk") 仍能正确解出 []byte("hi")
大文件或流式处理应避免 EncodeToString / DecodeString
这两个函数把整个输入加载进内存再返回新字符串或切片，对大 payload（如几 MB 的图片 base64）会造成明显 GC 压力和内存峰值。
替代方案是使用 Encoder 和 Decoder 配合 io.Writer/io.Reader：
- 用
base64.NewEncoder(w, src)将字节流实时编码写入w - 用
base64.NewDecoder(src, r)从 reader 实时解码 - 适合处理 HTTP body、文件读写、网络流等场景
关键点：编码器不会自动 flush，写完需调用 Close() 否则末尾字符可能丢失。
真正容易被忽略的是编码器/解码器的生命周期管理——尤其是嵌套在 HTTP handler 中时，忘记 Close() 或误复用 Encoder 实例，会导致输出截断或 panic。
