位运算+静态查表是唯一零堆分配、缓存友好的base32编解码方案，因base32按5位分组而char为8位，需拼接比特流并严格遵循rfc 4648补零规则与填充要求。
直接用位运算+静态查表，不分配临时 buffer，不逐字节 push_back —— 这是唯一能保证零堆分配、常数级缓存友好的做法。
为什么不能用 std::string 逐字节转 uint8_t 后硬套查表
因为 Base32 是按 5 位分组的，而 char 是 8 位；直接把每个 char 当作一个独立字节去查表，会破坏比特流连续性。例如 "a"（0x61 = 0b01100001）必须和后续字节拼成 40 位（5 字节）再拆成 8 组 5 位 —— 中间任何一次字节对齐截断都会丢位或补错零。
- 常见错误：把
std::string的每个c强转为uint8_t后右移/掩码取 5 位，结果在输入长度非 5 倍数时，末尾补零位置错乱，导致encode("ab")输出MFRA====（非法），正确应为MFRGG=== - 更隐蔽的问题：如果没强制
(unsigned char)c，在有符号char平台（如 GCC 默认）上，\xFF会被提升为负值，左移触发未定义行为 - RFC 4648 要求补零必须在比特流末尾（左对齐后补），不是在字节数组末尾填
'\0'—— 这点被多数手写实现忽略
base32_encode 必须预分配输出缓冲并跟踪 bit 位置
输出长度不是简单 input.size() * 8 / 5，而是向上取整到最接近的 8 的倍数（因为每 5 字节 → 8 字符）。同时，填充符 '=' 数量由 input.size() % 5 决定：余 0→0 个，余 1→6 个，余 2→4 个，余 3→3 个，余 4→1 个。
- 预分配公式：
out.reserve(((in.size() * 8 + 4) / 5 + 7) / 8 * 8)—— 先算理论字符数，再向上取整到 8 的倍数 - 别用
std::string::reserve()就完事：它只预留内存，不保证后续push_back不 realloc；应直接用std::string out(expected_len, '\0')或 raw buffer +resize() - 核心状态变量：
uint64_t bits存当前未消费比特（高位对齐），size_t bit_pos记已读总位数；每次从输入取 1 字节，左移拼入bits，再循环抽 5 位查表 - 查表必须是
static constexpr char table[32]，内容为"ABCDEFGHIJKLMNOPQRSTUVWXYZ234567"，避免运行时构造开销
base32_decode 需要反向映射表与严格校验
解码比编码更易出错：不仅要查表还原 5 位，还要处理填充、非法字符、长度非 8 倍数等问题。RFC 4648 明确要求填充符只能出现在末尾，且数量必须合法。
- 反向映射表建议用
std::array<uint8_t></uint8_t>（或 C 风格uint8_t rev_map[128]），初始化为0xFF，仅对合法字符赋值索引；访问前先检查c - 输入长度必须是 8 的倍数，否则直接拒绝；末尾
'='数量必须匹配input.size() % 8：0→0 个，1→6 个，2→4 个，3→3 个，4→1 个 —— 其他情况视为损坏数据 - 解码时仍需用
bit_pos累计已写位数，每凑够 8 位才写入一个uint8_t到输出 buffer；最后按原始字节数截断（input.size() * 5 / 8向下取整） - 所有输入字符必须先转
unsigned char再查表，否则大小写混用或控制字符会导致越界读
真正难的不是逻辑，而是边界：补零位置、填充数量、bit_pos 溢出、符号扩展、buffer 生命周期 —— 这些地方错一个，编码就不可逆。用 std::string_view 传参没问题，但别在函数里存它的 .data() 地址跨调用；查表必须 constexpr；输出 buffer 必须精确预分配。其他都是次要的。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
