Base64解码失败主因是输入含换行/空格、未用二进制模式写PDF、或解码库处理不当；需清理空白、校验字符集与长度、用std::ios::binary写入、验证%PDF头及字节精度。
Base64 解码失败：std::string 里混入了换行或空格
Base64 字符串从邮件、HTTP 响应或 JSON 中拿到时，常带 \r\n、空格或前后空白——这些字符不会被标准 Base64 解码函数识别，直接导致解码后数据长度异常、PDF 头损坏（比如打开提示“损坏的文件”或直接空白）。
实操建议：
- 用
std::remove_if+std::isspace清理所有空白字符，别只删首尾（std::string::erase配find_first_not_of不够） - 确认输入只含 Base64 字符集：
A-Z a-z 0-9 + / =，其他字符（如 URL 安全变体里的-和_）需先替换回+和/ - 长度必须是 4 的倍数，不足则补
=；但别盲目补——先检查原始字符串是否被截断
解码后写入 PDF：用 std::ofstream 必须加 std::ios::binary
这是最常踩的坑：用默认文本模式写二进制数据，Windows 下会把 \n（0x0A）悄悄转成 \r\n（0x0D 0x0A），PDF 的 %PDF-1.7 头或交叉引用表立刻失效，Acrobat 直接报“不是有效的 PDF”。
实操建议：
- 打开文件时明确指定模式：
std::ofstream file("out.pdf", std::ios::binary) - 写入前确认解码结果是
std::vector或std::string（注意：不能用std::string.c_str()传给write()，除非确保里面没嵌入\0；更安全的是用data(), size()） - 写完别忘了
file.close()或让作用域自动析构——否则部分数据可能滞留在缓冲区没落盘
选哪个 Base64 解码库：手写 vs boost::beast::detail::base64_decode vs OpenSSL
手写解码容易漏边界（比如等号填充处理错误），OpenSSL 依赖重且 API 冗长；boost::beast::detail::base64_decode 是轻量、无外部依赖、专为二进制设计的选项，但要注意它不校验输入合法性——非法字符会导致静默截断。
实操建议：
- 若已用 Boost，直接用
boost::beast::detail::base64_decode，它返回std::vector<:uint8_t>，天然适配二进制写入 - 若不想引 Boost，用 OpenSSL 的
EVP_DecodeBlock，但注意它会忽略换行、自动处理填充，且要求输入长度为 4 倍数（需提前补=） - 避免用某些 C++11 以前的“教学型”手写实现——它们常把
char当有符号类型处理，导致高位字节解错（PDF 里大量 0xFF 数据会出问题）
验证 PDF 是否写对：别只看文件大小，要查 magic bytes 和 header
解码+写入流程看似跑通，但 PDF 文件开头不是 %PDF- 或第 6 字节不是版本数字（如 1），基本可以判定解码或写入环节出错了。文件大小对不上只是表象，真正问题是二进制流被污染。
实操建议：
- 用十六进制工具（如
xxd out.pdf | head -n 2）确认前 8 字节是25 50 44 46 2d 31 2e 37（即%PDF-1.7） - 解码后立即检查输出 buffer 长度是否与原始 Base64 长度大致匹配（理论比例是 3:4，比如 1200 字符 Base64 应得约 900 字节二进制）
- 在写入前加一句
assert(decoded_data.size() > 10 && decoded_data[0] == 0x25 && decoded_data[1] == 0x50);，早发现问题
真正麻烦的不是解码本身，而是 Base64 输入来源不可控、二进制写入模式容易被忽略、以及 PDF 对字节精度零容忍——这三个点卡住，比算法逻辑难调十倍。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
