优先使用 cpp-base64 库而非手写：头文件单个、无依赖、默认不换行、安全支持二进制数据；避免 std::string 截断，写文本文件无需 binary 模式，读取前需清理空白并校验长度。
Base64 编码函数选 base64_encode 还是自己写？
别自己造轮子。C++ 标准库不带 Base64，但用 openssl 的 BIO_b64_new 或轻量级实现（如 cpp-base64）更稳。自己手写容易漏掉填充（=）、换行、字节对齐问题，尤其二进制图片数据边界模糊时，解码端一读就错。
推荐用 cpp-base64：头文件仅一个，无依赖，支持 encode / decode，且默认不换行——文本文件里塞 Base64 最怕意外换行被当内容截断。
- 确认图片数据是原始字节流（比如
std::vector<uint8_t>），不是经过 JPEG 解码的 RGB 像素数组 - 编码前别先转成
std::string再传入——含\0的二进制会提前截断；直接传data.data()和data.size() - 输出结果是纯 ASCII 字符串，可安全存入 UTF-8 文本文件，无需额外转码
写入文本文件时，std::ofstream 要开 std::ios::binary 吗？
不用。Base64 编码后全是可打印 ASCII（A–Z, a–z, 0–9, +, /, =），写文本文件用默认模式即可。开了 binary 反而可能在 Windows 下让换行变成 \r\n，若你手动加了换行分隔，就得统一处理；没加换行就更干净。
- 文件名建议带
.b64或.txt后缀，避免误当二进制打开 - 写入前可加一行说明头，比如
"// image: logo.png, size: 12480 bytes"，用//开头，不影响 Base64 解码 - 别用
<<直接写std::string—— 某些编译器对含\0的 string 处理异常；改用write(s.c_str(), s.length())
读取时 Base64 解码失败，常见错误是哪几类？
十次有八次是编码端多写了换行或空格，或者读文件时把 BOM 当内容读进去了。Base64 对输入极其敏感：长度必须是 4 的倍数，字符只能是那 64 个+填充符，中间不能有空白。
立即学习“C++免费学习笔记（深入）”；
- 读文件后，用
erase(remove_if(... isspace ...))清掉所有空白（包括\r,\n,\t, - 检查字符串长度 % 4 是否为 0；不是就补
=（最多补两个） - 用
base64_decode返回值判断是否成功——它通常返回解码后字节数，-1 表示非法输入 - 别假设文件一定以
\n结尾；用std::getline读整行再拼接，不如一次性read全部内容到std::string
性能和兼容性：大图（>5MB）要不要分块 Base64？
不用分块。Base64 是纯内存计算，编码耗时主要在 CPU，和图片大小线性相关；5MB 原图 Base64 后约 6.7MB 字符串，在现代机器上几毫秒搞定。真正卡的是后续操作：比如把 6MB 字符串一次性 push_back 到 std::string，可能触发多次内存重分配。
- 预分配空间：
result.reserve((data.size() * 4 / 3) + 4)，避免反复扩容 - 如果最终要嵌入 JSON 或 HTML，注意 Base64 字符串长度超 10KB 时，某些老旧 JSON 解析器会报“字符串过长”——这不是 Base64 问题，是宿主环境限制
- 移动端或嵌入式环境慎用 OpenSSL：体积大、链接复杂；优先选 header-only 的
cpp-base64
最麻烦的其实是路径和权限：写文件前确认目录存在、有写权限，否则 ofstream 构造失败也不报错，静默丢数据。这点比 Base64 本身还容易忽略。
