纯 Go 的 EqualBytes 未发挥 CPU 硬件能力，因 Go 编译器不为 bytes.Equal 自动生成 SIMD 代码，需手写 Plan9 汇编调用 vpcmpeqb 等指令，并严格满足地址对齐、长度校验、运行时 AVX2 检测三条件，且必须添加 VZEROUPPER 和 //go:noescape 防崩溃。
纯 Go 实现的 EqualBytes 在 4MB 字符串比较时耗时近 3.5ms，这不是“不够快”，而是**完全没发挥 CPU 硬件能力**——SIMD 路径下同等数据量可压到 200μs 以内，提升超 15 倍。但直接上 AVX2 不等于自动变快，关键在对齐、长度校验和运行时兜底。
为什么 Go 原生字符串比较不走 SIMD
Go 编译器（即使 GOAMD64=v3）不会为 == 或 bytes.Equal 自动生成向量化代码：这类操作涉及短路退出（首个字节不等就返回）、长度前置判断、边界检查，而自动向量化要求循环结构规整、无分支、内存访问连续——标准库的实现主动规避了这些前提。
- 编译器无法假设用户传入的切片地址是 32 字节对齐的
-
bytes.Equal必须兼容任意长度（包括 0、1、7 字节），而 AVX2 指令如vpcmpeqb天然要求批量处理 32 字节 - Go 运行时 GC 需要精确追踪指针，汇编函数若未正确标记栈帧，可能造成底层数组被误回收
手写 AVX2 字符串比较的硬性条件
想用 vpcmpeqb + vpmovmskb 加速，必须同时满足三个条件，缺一不可：
-
地址对齐：源切片底层数组起始地址需 32 字节对齐，否则触发 #GP 异常；可用
ANDQ $-32, AX截断获取对齐基址，再单独处理头尾 0–31 字节 -
长度校验：调用前必须检查
CX >= 32，否则跳过 AVX 路径；小数据量走纯 Go 循环反而更快（AVX 指令有固定开销） -
运行时检测：不能依赖
runtime/internal/sys.HasAVX2（它是编译期常量），必须手写 cpuid 汇编读取 ECX 第 5 位，或用golang.org/x/sys/cpu的CPU.AVX2字段
容易崩溃的两个隐藏坑
这两个问题在 benchmark 里不暴露，上线后才突然 panic：
立即学习“go语言免费学习笔记（深入）”；
-
漏写
VZEROUPPER：AVX2 指令会污染 upper 128 位 YMM 寄存器，若后续调用 SSE 函数（比如标准库的crypto/sha256），CPU 可能执行非法指令并 crash。这是最常被忽略的收尾动作 -
未标记 noescape：汇编函数参数若含
[]byte，Go 编译器默认认为其底层数组可能逃逸到堆，导致 GC 提前回收；必须加//go:noescape注释，且函数签名中用*byte+ 长度显式传参
Go 1.26 的新变量：SIMD 实验性支持还没落地
虽然 Go 1.26 宣称“SIMD 加速”，但实际仅限编译器内部优化（如 float64 数组求和），并未开放用户可调用的 SIMD API 或 intrinsics。所有向量化仍需手写 Plan9 汇编，且必须严格遵循寄存器命名规则：VPCMPEQB X0, X1, X2（不是 %xmm0），源/目标顺序不可颠倒。
真正要安全用起来，得自己封装一套带 cpuid 分发、对齐补偿、余数回退、VZEROUPPER 清理的函数族——这活儿没法偷懒，少一步都可能在线上环境静默崩溃。
