Base64 编码值得用 SIMD 加速，因其固定分组特性适合并行处理32字节输入，消除每字节查表与分支开销；但需对齐内存、分段查四张表、标量处理padding与异常，且ARM64需重写逻辑。
Base64 编码为什么值得用 SIMD 加速
普通 Base64 编码在 C++ 里用查表法（64 字节 lookup table）已经很快，但遇到大量小 buffer（比如 HTTP header、JSON 字段、protobuf payload）或高吞吐场景（日志批量编码、内存数据库序列化），CPU 在查表 + 移位 + 分支上仍会频繁停顿。SIMD 的价值不在于“单次更快”，而在于「一次处理 16/32 字节输入，消除每字节的独立逻辑判断」——尤其适合 Base64 这种固定分组（每 3 字节 → 4 字符）、可并行映射的转换。
但别指望 _mm256_shuffle_epi8 一贴就提速 5×：实际收益取决于数据长度、对齐、编译器内联能力，以及你是否把非向量化部分（比如末尾 padding 处理、输入长度模 3 的分支）拖慢了整条流水线。
用 AVX2 实现 32 字节/批的 Base64 编码（Clang/GCC 友好）
核心思路是把 3 字节一组的原始数据，打包成 32 字节输入（即 10 组完整 3 字节 + 2 字节余量），用 AVX2 指令并行提取 bit、重排、查表。关键不是手写所有 shuffle，而是复用成熟模式：
- 输入必须 32 字节对齐（否则
_mm256_loadu_si256会降速；用alignas(32)或posix_memalign分配） - 先用
_mm256_lddqu_si256（较旧 CPU 兼容）或_mm256_load_si256读入 - 用三轮
_mm256_srli_epi16+_mm256_slli_epi16提取高 6bit / 中 6bit / 低 6bit，再拼成 32 个 6-bit 索引 - 查表不能用普通数组——要转成 4 个
_mm256_shuffle_epi8查 4 个 64 字节表（A-Z、a-z、0-9、+/），最后拼接 - 输出时注意：32 字节输入 → 42 字节 Base64（32 / 3 × 4 ≈ 42.66 → 向上取整到 44），末尾可能需补
=，这部分必须退出 SIMD 回到标量逻辑
示例关键片段（简化）：
立即学习“C++免费学习笔记（深入）”；
__m256i input = _mm256_load_si256((__m256i*)src); __m256i lo6 = _mm256_and_si256(input, mask_0x3f); __m256i mid6 = _mm256_and_si256(_mm256_srli_epi16(input, 6), mask_0x3f); __m256i hi6 = _mm256_and_si256(_mm256_srli_epi16(input, 12), mask_0x3f); // ... 接着用 _mm256_shuffle_epi8 查四张表，合并
解码比编码更难加速，尤其对非法输入
Base64 解码天然有依赖：每个字符要查表得 6bit，再按位置拼回 3 字节 —— 但查表结果可能非法（>、?、空格等），此时必须中断并报错。SIMD 解码的常见坑是「假装所有输入都合法」，导致非法字符被静默转成 0 或触发越界读。
- 必须在查表前过滤非法字符：用
_mm256_cmpeq_epi8对照合法字符集（如"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"）做批量比对，生成 mask - 用
_mm256_movemask_epi8提取 mask 判断是否有非法位；有则退回到标量解码，避免未定义行为 - padding 字符
=不能简单忽略——要检查是否出现在非末尾位置（如"ab==c"是非法的），这个逻辑无法向量化，必须标量处理 - Clang 15+ 和 GCC 12+ 对
std::from_charsbase64 解码无原生支持，别指望标准库自动 SIMD 化
别直接抄 GitHub 上的 simd-base64 库
很多开源实现（如 simd-base64、base64simd）默认只开 AVX2，且假设输入长度 ≥ 64 字节、全部可读、无嵌入 null —— 这在真实服务中极易崩。实测发现三个高频断裂点：
- 输入长度 % 4 != 0 时，某些库直接 segfault（没检查 padding 数量）
- 用
_mm256_i32gather_epi32查表但没确保表地址 32 字节对齐，导致某些 Skylake CPU 报#GP - 返回的
std::string内存由 SIMD buffer 直接 move，但 buffer 是栈分配（alignas(32) char buf[256]），离开作用域就 dangling
真正稳妥的做法：只取其核心 shuffle 模式，自己封装成函数，输入校验、padding 处理、异常路径全部用标量写死；AVX2 路径仅作为 length > 64 且 is_aligned 的 fast path。
最易被忽略的一点：SIMD Base64 在 ARM64（NEON）上指令语义和 x86 不同，vqtbl1q_u8 查表方式、移位方向、甚至 padding 字符的判定逻辑都要重写——别拿 x86 代码 -march=arm64 硬编译。
