Base32编码不能逐字节查表，因其将输入视为连续比特流，每5位分组跨字节边界；须用uint64_t缓存比特、静态查表、预分配缓冲，并严格遵循RFC 4648填充与长度规则。
Base32编码为什么不能用for (auto c : input)逐字节查表
因为Base32不是字节到字符的映射，而是把整个输入当比特流重分组：每5位一组，跨字节边界。直接对std::string每个char转uint8_t再右移取高5位，会切断字节间连续性。比如"ab"是0x61 0x62 → 0b0110000101100010（16位），必须补4个0成20位后拆成4组5位；逐字节处理则变成两组独立8位，输出完全错误。
- 所有原始字节必须先转
unsigned char，否则在char有符号平台（如GCC默认）上，\xFF提升为负值，右移行为未定义 - 查表前必须从连续比特流中精确截取5位，起始位置由累计位偏移决定，不是固定在单字节内移位
- 补零是补“比特”，不是补字符
'0'或字符串"0000"；补完后还要截断到整数个5位组，否则解码器拒绝识别
uint64_t位缓存 + 静态查表的零堆分配编码
核心是用一个uint64_t当高位对齐的比特寄存器，避免std::vector::push_back或std::string::append触发多次realloc。不new、不resize中间buffer，纯位运算推进。
-
bits初始化为0，bit_pos = 0记录已填入位数；每次读入字节：bits |= static_cast<uint64_t>(byte) （左对齐塞高位）</uint64_t> - 只要
bit_pos >= 5，就取(bits >> 59) & 0x1F（因bits高位对齐，右移59得最高5位），查static constexpr char table[32] - 输出buffer必须预分配：
out_len = ((input_len * 8 + 4) / 5 + 7) / 8 * 8（向上取整到8的倍数，RFC强制要求） -
table必须硬编码为"ABCDEFGHIJKLMNOPQRSTUVWXYZ234567"，不能拼接、不能动态构造
解码时如何安全处理'='填充和非法字符
解码比编码更容易崩溃：填充位置错、大小写混用、非表字符（如'0'、'O'、'l'）都会导致越界或逻辑错乱。不能靠std::string::find查表——没检查npos就当索引用，下标直接越界。
- 预构建
std::array<int8_t></int8_t>反向映射表，合法字符ASCII映射到0–31，非法字符设为-1；查表O(1)，无分支 -
'='只能出现在末尾，且数量只允许0/1/3/4/6个（对应input_len % 5余数为0/4/2/3/1）；中间出现或数量不符，立即抛std::invalid_argument - 输入长度必须是8的倍数，否则直接拒绝；空白符需提前strip，不能留到查表阶段
- 解码输出长度固定：
fromBase32Length(encoded_len) = (encoded_len * 5) / 8（整除，因填充不贡献有效比特）
std::string_view传参 + 预分配缓冲区的实操细节
用std::string_view能避免拷贝，但别直接拿.data()当const uint8_t*用——若view来自std::vector<char>::data()</char>且vector后续resize，指针悬空。函数内安全，因string_view保证数据生命周期到函数返回。
立即学习“C++免费学习笔记（深入）”；
- 函数签名应为：
std::string base32_encode(std::string_view input) - 内部用
input.data()和input.size()没问题；但若需兼容C++17以下，改用const std::string&+.data()/.size() - reserve公式必须严格：
out.reserve(((in.size() * 8 + 4) / 5 + 7) / 8 * 8)；写成in.size() * 8 / 5会少1字符，触发扩容 - 别用
std::bitset拼接比特——它不支持动态长度，且转换开销大；也别用std::format或std::to_string做位提取，太慢
真正难的不是写出能跑的代码，而是让"a"编出"ME======、"ab"编出"MFRGG===、""编出"========，同时不崩在\xFF\xFF或含'o'/'0'的输入上——所有边界都得对齐RFC 4648，缺一不可。
