应复用成熟base64实现而非手写查表，注意输入长度需为4的倍数、padding合法、字符仅限A-Za-z0-9+/=，解码失败常因非法字符或padding错误，避免std::string含\0截断，慎用WinAPI需指定CRYPT_STRING_BASE64标志。
用 std::string 做 base64 编码，别手写查表逻辑
标准库不带 base64，但没必要从零实现查表和位运算。主流做法是复用成熟、轻量、无依赖的实现，比如 boost::beast::detail::base64（C++17+），或更常见的——抄一段经过验证的 50 行左右的纯函数。
手写容易错在：6-bit 分组越界、补 = 个数算错、输入含非法字符时没处理、忽略字节对齐导致末尾解码乱码。
- 直接用
std::vector<unsigned char></unsigned>当输入，避免std::string含\0截断问题 - 编码函数返回
std::string，只含 ASCII 字符（A–Z, a–z, 0–9,+,/,=） - 如果要支持 URL 安全变种（
-/_替代+//），得额外加参数或换函数，别混用
解码失败时大概率是 padding 或非法字符
常见报错不是抛异常，而是静默截断或返回空串/错误长度——比如解码结果长度不是 3 的倍数，说明输入有问题。
典型错误现象：base64_decode("ab==") 返回空；base64_decode("ab=c") 解出乱码；base64_decode("abc")（少 padding）可能崩在索引访问。
立即学习“C++免费学习笔记（深入）”；
- 必须检查输入长度是否为 4 的倍数，否则提前返回错误（如返回
std::nullopt或 throw） - 每个字符都要查 base64 字典表，遇到不在
A-Za-z0-9+/=中的字符（比如空格、换行、中文），立刻拒绝 - padding 只能出现在末尾，且最多两个
=；===或a==b都非法
Windows 下用 CryptStringToBinaryA 要小心编码和缓冲区
WinAPI 提供了 CryptStringToBinaryA 和 CryptBinaryToStringA，但它们默认按 ANSI 处理字符串，在中文系统上容易把 base64 字符误当本地编码解析，尤其输入含 + / 时可能被转义。
- 务必传
CRYPT_STRING_BASE64标志，别用CRYPT_STRING_BASE64HEADER（它期待 PEM 头） - 输出缓冲区大小必须预先调一次 API 获取所需长度，否则容易溢出或截断
- 输入
std::string必须确保只含 ASCII，且以\0结尾；用.c_str()安全，但别传std::string_view直接转指针
性能敏感场景下避免临时 std::string 拷贝
高频编解码（比如网络协议头处理）中，反复构造/析构 std::string 是明显瓶颈，尤其在小数据（
- 把编码函数改成接受
std::string_view输入 +std::back_insert_iterator输出，例如：base64_encode(std::string_view in, std::back_insert_iterator<:string> out)</:string> - 解码同理，输出用
std::span<:byte></:byte>或std::vector<:byte>&</:byte>引用传入，避免中间分配 - 别为了“统一接口”强行包装成
std::string返回——调用方自己管理 buffer 更可控
base64 看似简单，但边界条件多、隐性假设强，比如默认输入是干净 ASCII、不考虑流式分块、不处理换行符。实际嵌入协议栈时，这些地方最容易漏测。
