不能直接用std::string逐字节查表编码Base32，因为Base32按5位分组而字节为8位，必须将输入视为连续比特流，通过位运算跨字节拼接、左对齐、末尾补0至5位倍数后截断，再每5位查表；否则会导致位边界错乱、补零错误、填充数错误及有符号char移位未定义行为。
直接用 std::string 逐字节查表编码 Base32 必然出错——因为 Base32 是按 5 位分组的，而字节是 8 位，跨字节边界必须用位运算拼接，否则末尾补零位置错、索引偏移错、填充数错，连 "a" 都会编成非法结果。
为什么不能把 input[i] 直接转成 uint8_t 后查表
常见错误是写成这样：
for (size_t i = 0; i < in.size(); ++i) {
uint8_t b = static_cast<uint8_t>(in[i]);
idx = b >> 3; // 错！只取高 5 位，丢掉低 3 位
out += table[idx];
}这相当于强行按字节切片，完全无视 RFC 4648 要求的“比特流左对齐 + 末尾补零至 5 位倍数”。真实输入 "ab"（0x6162 → 0b0110000101100010）共 16 位，需补 4 个 0 成 20 位，再拆为 4 组 5 位；但上述逻辑会切成两个独立字节，产出完全错误的字符序列。
- 所有原始字节必须先转
unsigned char，否则在有符号char平台（如 GCC 默认）上，\xFF会被提升为负值，右移行为未定义 - 查表前必须从连续比特流中精确截取 5 位，起始位置由累计位偏移
bit_pos决定，不是固定字节内移位 - 补零是补“比特”，不是补字符
'0'或字符串"0000"；补零后还要截断到整数个 5 位组，否则解码器拒绝识别
如何用 uint64_t + 位运算实现零堆分配编码
核心是把输入当比特流读，用一个 uint64_t bits 当缓冲寄存器，高位对齐，每次取最高 5 位查表，然后左移腾出空间。这样避免 std::vector::push_back 或 std::string::append 触发多次 realloc。
立即学习“C++免费学习笔记（深入）”；
-
bits初始化为 0，bit_pos = 0记录当前已填入多少位 - 每读一个字节：
bits |= static_cast<uint64_t>(byte) ，把新字节塞进高位空闲区</uint64_t> - 只要
bit_pos >= 5，就执行：idx = (bits >> 59) & 0x1F（右移 59 保证取最高 5 位），查table[idx]，然后bits - 输出 buffer 必须预分配：
out_len = ((in.size() * 8 + 4) / 5)（向上取整），再向上对齐到 8 的倍数（RFC 要求输出长度为 8 倍数）
填充 '=' 的数量怎么算才不翻车
填充数不由“输出长度 mod 8”决定，而是由原始字节数 len % 5 严格映射：
-
len % 5 == 0→ 0 个'=' -
len % 5 == 1→ 6 个'=' -
len % 5 == 2→ 4 个'=' -
len % 5 == 3→ 3 个'=' -
len % 5 == 4→ 1 个'='
别用 output.append(n, '=') 动态追加——它可能触发内存重分配；应该一开始就 output.resize(expected_total_len)，其中 expected_total_len = ((len * 8 + 4) / 5 + 7) / 8 * 8，再用指针或迭代器填入有效字符，最后让 resize 补齐 '='。
用 std::string_view 输入时最易忽略的陷阱
std::string_view input 看似安全，但若你写 const uint8_t* p = reinterpret_cast<const uint8_t>(input.data())</const>，再传给底层 C 风格函数，就埋了隐患：如果 input 来自临时 std::string("hello")，生命周期只到表达式结束，而你的位运算循环可能跨多轮，导致读野指针。
- 正确做法：在函数开头立刻拷贝
input.data()到栈数组（限小数据）或用std::span<const std::byte></const>（C++20）约束生命周期 - 更稳妥的是直接用
input.begin()/input.end()迭代，配合std::distance算长度，避免裸指针 - 查表必须用
static constexpr char table[32]，不能用std::array或局部std::string，否则每次调用都构造，破坏零开销抽象
真正难的不是写出能跑通的版本，而是让 base32_encode("a") 输出 "ME====== 而不是 "ME======" ——后者看似只差一个 =，但已是非法 Base32，TOTP 密钥导入会失败。补零位数、截断时机、填充计数，三者必须同步对齐 RFC 4648，差一位就全盘作废。
