avx2汇编加速仅在数据≥64字节、32字节对齐、无分支且不依赖go运行时条件下成立；否则易panic或结果错误，须严格遵循签名、文件名、符号定义、cpuid检测、vzeroupper及禁止call等契约。
能加速，但只在特定条件下成立：数据长度 ≥ 64 字节、地址 32 字节对齐、校验逻辑无分支且不依赖 Go 运行时——否则不仅没收益，还容易 panic 或结果错。
AVX2 汇编函数怎么写才不会崩溃
崩溃最常见原因不是指令写错，而是违反 Go 汇编的调用契约。汇编函数不是独立二进制，它必须和 Go 运行时协同工作。
- 函数签名必须严格匹配：
func avx2Checksum(data *byte, len int) uint64，不能多参数、不能带context.Context或其他 Go 类型 - 汇编文件名必须是
crc32c_amd64.s（包名+架构），且和 .go 文件同目录、同包；函数符号必须写成TEXT ·avx2Checksum(SB), NOSPLIT, $0-40，其中·是 Unicode 中点（U+00B7），不是英文句点 - 入口处必须做 CPUID 检测（读 ECX 第 5 位），失败则跳转到标量 fallback；结尾必须插
VZEROUPPER，否则后续调用任何 SSE 函数（比如crypto/aes）会触发illegal instruction - 不能出现
call指令调用任何 Go 函数（包括println），也不能分配堆内存；调试只能靠gdb查ymm0–ymm7寄存器值
内存地址不对齐会导致什么
AVX2 的 vpmovzxbd、vpcmpgtb 等指令要求源操作数地址 32 字节对齐，否则直接触发 #GP(0) 异常，进程退出，recover 不起作用。
- 网络缓冲区（如
conn.Read()返回的[]byte）通常不满足对齐，必须手动对齐：用ANDQ $-32, AX截断起始地址，头尾 0–31 字节用标量循环单独处理 - 推荐方式是提前分配对齐内存：
aligned := (*[1 ，再把数据 copy 过去 - 加载数据时不能写
MOVQ src_base+0(FP), X0（X0 是向量寄存器），必须先MOVQ src_base+0(FP), AX，再VMOVDQU (AX), X0
为什么校验结果和标量实现不一致
最常见两个原因：字节序误判 + 进位丢失。AVX2 指令行为和标量加法/异或有本质差异，不能简单替换。
-
vpaddd是饱和加法，而校验常用模2^64加法；若用它累加uint64切片，高位溢出会被截断。正确做法是用vpxor做异或校验，或用vpaddq+ 手动进位链（vpsrlq $63, ymm, ymm提取进位位） -
Go的[]byte是小端序，AVX2 加载后低地址字节仍在 YMM 寄存器低位，无需翻转；但若用了vpackuswb压缩指令，布局会被打乱，导致结果错 - 长连接中数据往往几 MB，不能全载入 YMM 寄存器。必须按 64 字节（2×YMM）为单位循环处理，剩余
len % 64部分切回 SSE 或标量路径——AVX2 不支持非对齐短加载
真正难的不是写汇编指令，而是让整个链条严丝合缝：CPU 检测、内存对齐、寄存器清理、栈帧定义、符号暴露，漏掉任意一环，要么 panic，要么静默错误。别在没压测出热点前动手写；也别信“写了就快”，得用 pprof 确认标量循环真占 CPU >25% 再进汇编层。
