go汇编函数需声明完整签名、命名匹配包名+架构（如crc32c_amd64.s）、符号用text·funcname(sb)定义且含正确栈帧；必须做cpuid检测、32字节内存对齐、vzeroupper结尾，否则崩溃或结果错误。
Go 原生不支持在高级语法中调用 AVX2 指令，长连接场景下的关键数据校验（如 CRC32C、Adler32、自定义字节流哈希）若已占 CPU >25%，且 pprof 显示热点在标量循环里，才值得进汇编层重写——否则纯属过早优化。
怎么让 Go 汇编函数被正确链接和调用
常见错误是 undefined: crc32cAVX2 或运行时 panic，根本原因不是代码写错，而是符号没暴露给 Go 编译器。
- Go 文件中必须声明完整函数签名，哪怕空实现：
func crc32cAVX2(src []byte, init uint32) uint32 - 汇编文件名必须匹配包名+架构，例如
crc32c_amd64.s，且与.go文件同目录、同包 - 汇编函数名必须是
TEXT ·crc32cAVX2(SB), NOSPLIT, $0-40：注意那个·是 Unicode 中点（U+00B7），不是英文句点；$0-40表示栈帧 0 字节，参数+返回值共 40 字节（[]byte占 24 字节，uint32占 8 字节，返回值占 8 字节） - 不能放在
internal/或子模块下——Go 构建系统不会跨路径解析.s文件
AVX2 校验函数必须做的三件事
漏掉任意一项，要么崩溃，要么结果错，要么性能反降。这不是建议，是硬性约束。
- 运行时 CPU 检测：别信
runtime/internal/sys.HasAVX2，它只是编译机的静态标记。必须手写CPUID汇编读取ECX第 5 位，检测失败则 fallback 到 Go 标准实现 - 内存地址 32 字节对齐：校验算法常处理网络缓冲区，而
vpcmpgtb、vpslld等指令要求源地址对齐。用ANDQ $-32, AX截断起始地址，头尾 0–31 字节用标量指令单独处理 - 结尾必须插
VZEROUPPER：否则后续调用任何 SSE 函数（比如crypto/aes的 AES-NI 指令）会触发illegal instruction信号，进程直接退出，无法 recover
为什么不能直接把 []byte 地址塞进 X 寄存器
Go 汇编不支持寄存器间直接传切片，所有指针都得从栈或通用寄存器加载出来。
- 参数通过 FP 偏移获取：
src_base+0(FP)取底层数组指针，src_len+8(FP)取长度，init+16(FP)取初始值 - 别写
MOVQ src_base+0(FP), X0——X0是向量寄存器，不能直接加载内存地址；正确流程是先MOVQ src_base+0(FP), AX，再用VMOVDQU (AX), X0加载数据 - AVX2 校验常用指令如
VPCLMULQDQ（用于 CRC）、VPSRLD、VPADDD都要求操作数是寄存器或对齐内存，不能混用标量/向量寻址模式 - 长度检查必须前置：
CMPQ $32, CX，小于 32 字节直接跳过 AVX 路径——AVX2 处理 32 字节对齐块，小数据走 Go 循环反而更快
最容易被忽略的是：长连接场景下，校验逻辑常嵌在 read-loop 热路径里，而网络 buffer 多为 mmap 分配或 ring-buffer 管理，其地址天然不对齐。这时候头尾标量处理的分支预测失败率高，实际收益可能被抵消——务必用 go tool objdump -s crc32cAVX2 确认指令真实生成，再压测对比。
