Base32编码不能直接逐字节处理，因其按5位分组而ASCII为8位，需将输入视为比特流，用位运算+静态查表实现零堆分配编码，预分配输出缓冲并正确处理末尾补零与填充。
Base32编码为什么不能直接用std::string逐字节处理
因为Base32是按5位一组编码的，而ASCII字节是8位，直接按字节切分会导致位边界错乱。比如"A"（ASCII 65，二进制 01000001）必须和后续字节拼成40位（5字节=40位），再拆成8组5位——跳过字节对齐直接操作会丢位或补错零。
常见错误是把输入当UTF-8或Latin-1逐字符转uint8_t后硬套查表，结果在末尾填充时漏掉位移偏移，导致"hello"编码出错或崩溃。
- 输入长度不是5字节倍数时，必须在末尾补0位（不是补
'0'字符），再按5位切分 - 补位数 = (5 - len % 5) % 5，对应输出末尾补
'='的数量是补位字节数 × 8 / 5（向上取整） - 查表要用
static constexpr char table[32]，避免运行时构造开销
如何用位运算+查表实现零堆分配编码
核心是把输入字节数组当bit stream读，用size_t bit_pos跟踪当前位偏移，每次取5位查表。不申请临时buffer，不调用std::vector或std::string的push_back。
示例关键逻辑：
立即学习“C++免费学习笔记（深入）”；
for (size_t i = 0; i < input_len; ++i) {
uint8_t byte = static_cast<uint8_t>(input[i]);
bits |= static_cast<uint64_t>(byte) << (56 - (bit_pos % 8));
bit_pos += 8;
while (bit_pos >= 5 && out_pos < out_capacity) {
uint8_t idx = (bits >> 59) & 0x1F; // 取最高5位
output[out_pos++] = table[idx];
bits <<= 5;
bit_pos -= 5;
}
}-
bits用uint64_t足够覆盖最多7字节（56位）+ 5位，避免溢出重算 - 查表前右移
59是因为bits高位对齐，比用__builtin_clzll更可移植 - 输出buffer必须预先分配：输出长度 =
((input_len * 8 + 4) / 5)，向上取整
std::string_view输入 + std::string输出的现代写法要注意什么
用std::string_view传入能避免拷贝，但别在函数内直接取.data()然后当成const uint8_t*用——如果view指向临时std::string或字面量，生命周期没问题；但若view来自std::vector<char>::data()且vector可能resize，就危险。
- 函数签名建议：
std::string base32_encode(std::string_view input) - 内部用
input.data()安全，因string_view保证数据有效直到函数返回 - 不要用
std::string::reserve()代替精确预分配——它只预留内存，不保证capacity足够，仍可能触发realloc - 结尾填充
'='时，用output.resize(expected_len)而非循环赋值
性能瓶颈通常卡在哪儿
实测中，90%的耗时不在位运算或查表，而在内存分配和std::string的SBO（small string optimization）切换。比如编码1KB数据，如果输出string初始capacity=0，会触发多次realloc；而预分配后，速度提升2~3倍。
- 用
std::string ret; ret.reserve(expected_len);比std::string ret(expected_len, '\0')更快——后者初始化所有字节，前者只分配不填零 - 查表用
constexpr数组比std::array<char,32>略快，因前者是POD，无构造开销 - Clang下开启
-O2 -march=native能让bits >> 59被优化为shrq指令，GCC需-O3才稳定
真正难的是处理非5字节倍数的输入时，位移计数器和补位逻辑容易差1——多测几个长度为1、2、3、4、6的输入，比跑benchmark更能暴露bug。
