Base64解码前须确认CDATA完整、清理非法字符、校验长度为4的倍数，优先用OpenSSL的EVP_DecodeBlock解码并检查返回值，解析XML时需判空、避免误取节点名，并用std::vector<uint8_t>保存二进制结果，解码后立即校验文件魔数。
Base64解码前先确认XML中CDATA包裹是否完整
很多看似“解析失败”的问题，其实是XML里base64数据被截断或换行符干扰了。C++标准库（如tinyxml2或pugixml）读取CDATA时默认会保留空白和换行，但有些服务端生成的XML会在CDATA内硬换行、加空格甚至插入注释——这些都会让后续Base64解码失败，报invalid character或长度非4的倍数。
- 用
pugixml时，务必调用node.text().get()而非node.child_value()，后者会跳过空白并可能吞掉首尾空格（而Base64对换行敏感） - 拿到字符串后，先用
std::remove_if清理所有\r、\n、\t、=必须保留） - 检查长度：Base64编码后长度一定是4的倍数，如果不是，大概率是前端截断或传输中丢字节
用openssl/evp.h解码比手写循环更稳
自己实现Base64查表解码容易忽略填充处理（比如末尾一个或两个=）、大小写混用、非ASCII字符误判。OpenSSL的EVP_DecodeBlock底层已处理好边界情况，且支持任意长度输入（不强制要求null终止），适合嵌入到XML解析流程中。
- 别用
EVP_DecodeInit+EVP_DecodeUpdate——那是为流式解码设计的，单次解码反而多此一举 -
EVP_DecodeBlock返回值是实际解码字节数，**不是输入长度**；若返回-1，说明输入含非法字符（此时应打印原始字符串前32字节排查） - 输入缓冲区需额外+1字节（
EVP_DecodeBlock会尝试写\0，但实际不会用到；不加可能导致越界警告） - 示例关键片段：
int len = EVP_DecodeBlock(decoded_buf, reinterpret_cast<const unsigned char*>(b64_str.c_str()), b64_str.size());
tinyxml2读取节点内容时别漏掉GetText()的空指针检查
如果XML附件节点是空元素（如<data/>）或文本内容为空白，tinyxml2::XMLNode::GetText()直接返回nullptr。没做判空就传给Base64解码函数，程序大概率崩溃，错误堆栈还指向解码层，误导排查方向。
- 正确写法是：
const char* text = node->ToElement()->GetText(); if (!text || strlen(text) == 0) { /* 处理空数据 */ } - 不要依赖
node->FirstChild()->Value()——它返回的是子节点名，不是文本内容 - 若XML声明了
encoding="UTF-8"，但Base64解码后数据是二进制（比如PDF、图片），别试图用std::string存再转std::wstring，直接用std::vector<uint8_t>接住解码结果
解码后验证魔数比盲目std::cout更有效
Base64解码成功不代表附件内容可用。常见附件如PDF、PNG、ZIP都有固定文件头（魔数），解码后立刻校验，能快速区分是传输损坏还是服务端生成错误。
立即学习“C++免费学习笔记（深入）”；
- PNG：检查前8字节是否为
\x89\x50\x4E\x47\x0D\x0A\x1A\x0A - PDF：检查开头是否为
%PDF-（注意是ASCII字符串，不是二进制） - ZIP：检查前4字节是否为
\x50\x4B\x03\x04 - 如果魔数对不上，优先怀疑Base64字符串本身被XML解析器二次转义过（比如
变成<code>又变回<code><），这种嵌套转义在多层封装时极难肉眼发现
实际最难缠的不是解码逻辑，而是XML节点内容在DOM加载过程中被自动规范化——比如把]]>中间的]和]之间插入空格，或者把
实体还原成换行再参与Base64解码。这类问题必须用十六进制dump原始节点内存才能定位。
