Base32编码必须严格遵循RFC 4648标准：字符表为ABCDEFGHIJKLMNOPQRSTUVWXYZ234567，大小写需统一转大写，填充符=仅允许出现在末尾且数量须匹配输入长度模5规则，非法字符（如8、9、I、L、O）应立即报错，编码按5字节分组补bit而非byte，解码需显式截断冗余bit，推荐使用std::span<std::byte>和std::optional提升安全性与效率。
Base32编码表和索引映射必须严格按RFC 4648定义
Base32不是随便选32个字符拼出来的——ABCDEFGHIJKLMNOPQRSTUVWXYZ234567 这个顺序不能错，末尾的234567不是补位，是标准的一部分。很多手写实现用0123456789ABCDEFGHIJKLMNOPQRSTUV之类变体，会导致和其他系统（如TOTP、RFC 3548兼容工具）互不识别。
解码时更要小心：所有小写字母必须先转成大写再查表；遇到=填充符要校验位置（只能在末尾，且数量必须是0、1、3、4、6），否则直接拒绝。RFC明确要求忽略空格和换行，但实际中多数库默认不处理，需要自己std::remove_if预清洗。
编码时需按5字节分组并处理剩余字节数
Base32每5个原始字节（40 bit）生成8个编码字符（5×8=40 bit）。如果输入长度不是5的倍数，得补0凑整再编码，最后加=填充——但注意：补的是bit，不是byte。比如输入3字节（24 bit），补16个0 bit变成40 bit，对应8字符输出，其中最后==表示丢了16 bit信息。
- 输入长度 % 5 == 0 → 无填充
- 输入长度 % 5 == 1 → 补3个0字节 → 输出末尾
==== - 输入长度 % 5 == 2 → 补2个0字节 → 输出末尾
=== - 输入长度 % 5 == 3 → 补1个0字节 → 输出末尾
== - 输入长度 % 5 == 4 → 不补0字节 → 输出末尾
=
别用std::string::append硬拼=，应该在编码循环结束后根据余数算出填充数，再用resize补足。
立即学习“C++免费学习笔记（深入）”；
解码函数必须检查非法字符和填充位置
遇到8、9、I、L、O这些易混淆字符，应立刻返回错误——Base32标准表里根本没有它们。常见坑是把Base32和Base32hex（0-9A-V）搞混，后者用于DNSSEC等场景，二者不兼容。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
填充符=只允许出现在末尾，且数量必须匹配输入长度模5的结果。例如长度为12的Base32字符串（12%8==4），说明原始数据长度%5==4，所以只能有1个=；如果出现==，就是非法输入。
示例：解码MFRGG===时，先去掉=得MFRGG（5字符），对应5×5=25 bit → 原始字节数为3（25/8向下取整），但实际需还原为3字节，最后1字节的低3 bit 应丢弃（被补0覆盖）。这个截断逻辑必须显式写出，不能依赖static_cast自动截断。
C++17及以上建议用std::span<const std::byte>传入二进制数据
避免把std::string当二进制容器用——它隐含\0终止假设，而Base32常处理含\0的密钥或哈希值。用std::vector<std::byte>或std::span更安全。
编码函数签名建议：std::string base32_encode(std::span<const std::byte> data)</const>
解码函数签名建议：std::optional<:vector>> base32_decode(std::string_view encoded)</:vector>
返回std::optional比抛异常更合适——解码失败太常见（用户粘贴错、网络截断），不应让调用方被迫写try/catch。另外，std::string_view参数避免不必要的拷贝，尤其处理长token时。
真正难的不是算法本身，是边界条件：零长度输入、全填充、单字符输入、含换行的base32块——这些case几乎每个自研实现都漏过一两个。别信“跑通hello world就算对了”。
