C++标准库至今未提供Base64编解码函数，手写需严守RFC 4648：正确预分配、补零处理、末尾填充=、非法字符清洗、长度校验及使用std::vector避免c_str()截断风险。
C++ 标准库至今（C++23）不提供 Base64 编解码函数，必须手写或引入第三方库；手写实现可行、轻量，但几个关键点一错就解码失败或乱码——不是“写不出来”，而是“写得不够严”。
std::string 能安全存二进制数据，别把它当 C 字符串用
Base64 编解码操作的是原始字节流，输入可能是含 \0 的密钥、图片、JSON 二进制 blob。std::string 完全支持：它的 length() 返回真实字节数，data() 指向完整内存块。但若后续传给 C 风格 API（如 printf("%s", s.c_str()) 或旧版 OpenSSL），c_str() 会在首个 \0 截断——这不是解码错误，是误用。
- 调试时打印二进制内容，用循环输出十六进制：
for (auto b : output) printf("%02x ", (unsigned char)b); - 写入文件或 socket 时，务必用
output.data()和output.size()，而非c_str() - 若需兼容只接受 C 字符串的接口，且确认数据不含
\0（如纯 ASCII token），再用c_str()
编码函数必须预分配空间，且填充逻辑不能靠 if 判断长度
常见错误是边 push_back 边算填充，导致末尾 = 位置错位。正确做法是：先按公式预估容量，再逐组处理，最后统一补 =。
- 预分配：用
output.reserve(((input.length() + 2) / 3) * 4)，避免多次内存重分配 - 每组取 3 字节：不足时用
0补（不是跳过），再按位拆成 4 个 6 位值 - 填充只发生在末尾：输入长度 % 3 == 1 → 补两个
=；== 2 → 补一个=；绝不在中间插 - 字符表必须是
static const char base64_chars[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";，不可动态构造
解码前必须清洗非法字符，且长度校验不可省略
真实场景中，Base64 常来自 PEM（证书）、HTTP header 或用户粘贴，含换行、空格、-、_ 甚至 -----BEGIN 头尾。直接解码会查表越界或返回 -1 导致崩溃。
立即学习“C++免费学习笔记（深入）”；
- 清洗只需一行逻辑：遍历每个
char c，仅保留lookup[static_cast<unsigned char>(c)] >= 0</unsigned>的字符（lookup是 256 元素的int8_t数组） - 清洗后长度必须是 4 的倍数，否则立刻报错——不尝试补长、不忽略末尾垃圾
- 填充符
=只允许出现在末尾，且最多连续两个；中间出现=应拒绝（RFC 4648 强制要求） - 查表数组初始化时，所有非法字符（包括
\r、\n、空格）都设为-1
输出用 std::vector 更安全，尤其涉及加密或网络协议
虽然 std::string 能存任意字节，但语义上它常被理解为文本。一旦传入第三方库（如 OpenSSL 的 EVP_DecryptUpdate），或做 memcmp 比较，std::string 的隐式转换和生命周期管理容易出问题。
- 解码函数返回类型建议用
std::vector<uint8_t></uint8_t>：明确表示这是字节序列，无c_str()风险 - 编码函数可仍用
std::string（输出全是可打印 ASCII），但解码端保持类型一致更稳妥 - 若项目已用 OpenSSL：
EVP_DecodeBlock要求输入不含=，且长度必须是 4 的倍数；而boost::beast::detail::base64::decode支持带=的完整字符串，返回std::pair<size_t error_code></size_t>，参数含义差异大，别混用
真正难的不是写出能跑通的版本，而是让代码在面对 PEM 证书、用户乱粘贴、含中文的 JSON、空字节密钥这些情况时，既不崩溃也不静默出错——边界校验、字符清洗、类型选择，每一处松动都会在集成时暴露。
