base64解码函数必须严格处理填充字符和非法输入：输入长度须为4的倍数，预建256元查表（未定义字符设为-1），遇=停止并按数量截断字节，遇非法字符立即返回空vector；推荐用std::string_view输入和std::vector输出，并预分配缓冲区。
Base64解码函数必须处理填充字符和非法输入
标准Base64编码末尾可能含 = 或 == 填充，解码时若忽略会导致字节截断；更常见的是传入含空格、换行或非Base64字符（如 -、_）的字符串，直接查表会越界或返回错误结果。
建议用查表法实现：预建64元映射数组（'A'-'Z'、'a'-'z'、'0'-'9'、'+'、'/' 对应 0–63），对每个输入字符查表；遇到 = 则停止解码并按位置补零；遇到查表为 -1 的字符（即非法字符）应立即返回空 std::vector<uint8_t></uint8_t> 或抛异常。
- 查表数组索引用
static const int8_t kBase64DecodeTable[256]，未定义字符设为 -1，避免char符号扩展问题 - 输入长度必须是 4 的倍数，否则直接拒绝（不自动补
=） - 解码后输出长度 =
input.length() * 3 / 4，但需减去填充数对应的实际字节数（1个=减1字节，2个减2字节）
std::string_view + std::vector 是最实用的输入输出组合
原始二进制流本质是字节序列，std::string 用于存储二进制易引发误判（如含 \0 时 .c_str() 截断），而 std::vector<uint8_t></uint8_t> 语义清晰、无隐式转换风险。输入用 std::string_view 避免不必要的拷贝，尤其处理大Base64文本时更高效。
示例接口签名应为：std::vector<uint8_t> base64_decode(std::string_view input)</uint8_t>
- 不要接受
const std::string&——调用方可能传临时std::string，string_view更通用 - 输出不用
std::string存二进制——哪怕你后续要写入文件，也先存vector再用data()和size()获取指针/长度 - 若需兼容 C 接口，可用
output.data()和output.size()直接传给write()或fwrite()
注意URL安全Base64变种（-/_）需额外适配
标准Base64用 + 和 /，但URL/文件名中不允许，故常用变种将二者替换为 - 和 _。若解码函数只支持标准表，遇到 base64url 编码就会全错。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
解决方式有两种：一是预处理——把 - 替成 +、_ 替成 /；二是扩展查表——在解码表里让 - 和 _ 也映射到 62、63。后者更高效，但需确保初始化表时覆盖这两个字符。
- 检查输入是否含
-或_：若有，说明大概率是 base64url，用扩展表解码 - 不要混合处理——同一输入里既出现
+又出现-属于损坏数据，应拒绝 - IETF RFC 4648 明确区分 standard 和 url-safe，生产环境建议先探测再选表
性能关键点：避免逐字符 push_back，预先 reserve 容量
Base64解码输出长度可精确预估，若边解边 push_back，vector 可能多次 realloc，对几MB的Base64文本影响明显。
正确做法：先算出最大可能输出长度（(input.size() / 4) * 3），reserve 后用 resize 或直接用 data() 指针写入。
- 计算实际输出长度需在解码循环中动态调整（因填充数不确定），但 reserve 按上限值足够
- 用
output[i] = ...直接赋值比push_back快 2–3 倍（实测 clang++15 -O2） - 若编译器支持，可加
[[likely]]分支提示：正常字符分支标记为 likely，=和非法字符标 unlikely
实际中最容易被忽略的是填充校验逻辑——很多实现只检查末尾是否有 =，却没验证其位置是否合法（比如出现在中间）、数量是否为 1 或 2；还有人把 base64url 当作标准Base64硬解，结果高位字节全错。这些错误在小测试用例里不暴露，一到真实图片或JWT token就崩溃或解出乱码。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
