strings.Index 默认不用 AVX2 加速，因为多数场景输入长度随机、内存不对齐，强行使用会触发#GP异常；且需处理UTF-8边界、空串等复杂语义，AVX2无法全覆盖；标准库优先保障正确性与可移植性，仅对≥64字节且CPU支持的热路径有条件启用。
strings.Index 为什么默认不用 AVX2 加速
Go 标准库的 strings.Index 在 Go 1.21+ 中已对短字符串（≤64 字节）启用 PCMPSTRB 指令加速，但仅限 x86-64 且需运行时检测 CPU 支持；它不无条件启用 AVX2，因为：
– 大多数查找场景输入长度随机、内存地址不对齐，强行用 vmovdqu 会触发 #GP 异常
– strings.Index 要处理 UTF-8 边界、空字符串、重叠子串等逻辑，AVX2 纯向量化无法覆盖全部语义
– 标准库优先保证正确性与可移植性，AVX2 路径只在 pprof 确认为热路径且长度 ≥ 64 字节时才可能被编译器内联激活
AVX2 实现字符串查找的核心指令链
真正能提速的是固定模式、已知对齐、纯 ASCII 场景下的子串定位，典型指令组合是：
– VPBROADCASTB：把单字节 pattern 广播到 ymm0 全 32 字节
– VPCMPEQB：对齐读取 32 字节数据块，逐字节比对，生成掩码
– VPMOVMSKB：把 ymm 寄存器中每个字节的最高位提取为 32 位整数
– BSFQ：在该整数上找第一个置位 bit，即匹配起始偏移
– 需配合循环步进 + 余数标量回退（开头 ≤31 字节、结尾未满 32 字节）
必须手动做的三件事，漏一就崩溃或错结果
- 运行时 CPUID 检测：不能只靠
GOAMD64=v3，必须读取ECX第 5 位确认HasAVX2，否则老 CPU 直接illegal instruction - 内存地址 32 字节对齐：用
ANDQ $-32, AX截断指针，头尾用MOVBQZX+ 循环处理 - 结尾插
VZEROUPPER：否则后续调用 crypto/aes 或任何 SSE 函数会因寄存器状态污染而 panic
实际加速效果和临界点
实测表明：
– 模式长度 = 1 字节（如找 '\n'），AVX2 路径在 ≥ 128 字节输入时开始稳定快 3–4 倍
– 模式长度 = 4 字节以上，需多轮 VPCMPEQB + 移位对齐，收益快速下降；此时 strings.IndexByte（已内联 SIMD）反而更稳
– 若输入含大量非 ASCII 字符，UTF-8 解码开销会吃掉向量化收益，甚至更慢
