Go标准库crypto/aes在1.17+版本、amd64/arm64平台且未绕过标准接口时自动启用AES-NI；若调用符号含aesenc等指令则生效，否则回落纯Go实现。
Go 里 AES 加解密为什么没用上 AES-NI？
Go 标准库的 crypto/aes 在支持 AES-NI 的 CPU 上默认会自动启用硬件加速——但前提是：你用的是标准实现、没手动替换底层 block、且 Go 版本 ≥ 1.17（关键分水岭）。很多人测出性能没提升，其实是误用了非标准路径，比如自己封装了 cbc.Encrypt 却绕过了 aes.NewCipher 返回的硬件感知 cipher 实例。
常见错误现象：go test -bench=. 发现 AES-CTR 吞吐量卡在 300MB/s 左右（远低于理论 2GB+/s），perf top 显示大量 crypto/aes.(*aesCipherAsm).Encrypt 调用——这说明走的是汇编优化路径；但如果看到的是 crypto/aes.(*aesCipher).Encrypt（无 Asm 后缀），基本就是 fallback 到纯 Go 软实现。
- 确认是否启用：用
go env GOARCH确保是amd64或arm64（ARMv8.3+ 也有 AES 指令） - 避免手动拆解：别用
aes.NewCipher后再套一层自定义 block 接口，直接传给cipher.NewCBCEncrypter等标准构造器 - Go 1.16 及更早版本需打补丁或升级，AES-NI 自动探测逻辑在 1.17 才彻底稳定
如何验证 AES-NI 真正生效？
不能只看 benchmark 数字，得看执行时实际调用的函数符号和 CPU 指令特征。
最直接方式：在加解密循环里插入 runtime.LockOSThread()，然后用 perf record -e cycles,instructions,cpu/event=0x01,umask=0x02,name=aes/（Intel PMU 事件）采样；更简单的是检查 symbol：
立即学习“go语言免费学习笔记（深入）”；
go tool objdump -s "crypto/aes\..*Encrypt" your_binary | grep -E "(aesenc|aesenclast|aesdec)"
如果输出里有这些 x86 指令，说明汇编路径已命中。没有？那大概率被降级了。
- 检查
GODEBUG=gocacheverify=1是否干扰了 build cache 导致重编译进软实现 - 交叉编译时若指定
GOARCH=amd64但宿主机是 ARM，会强制 fallback —— 必须本地构建 -
go run默认不启用 build cache，小脚本测试容易误判，务必用go build && ./binary测
自己写汇编 or 用 golang.org/x/crypto？
标准库已覆盖主流模式（AES-GCM、CBC、CTR），golang.org/x/crypto 里多数 AES 相关包（如 chacha20poly1305）跟 AES-NI 无关；它只在 aes/gcm 里做了少量优化补充，但 1.19+ 标准库已反向合并。除非你要 AES-KW 或 CFB 这种冷门模式，否则别引入 x/crypto 增加维护负担。
自己手写 AVX512 汇编？没必要。Go 的 crypto/aes asm 实现已支持 256-bit keys + 128-bit blocks + 并行 4-block 处理，吞吐瓶颈通常卡在内存带宽或 Go runtime 的 GC 压力，而不是单指令延迟。
- 优先调大 buffer：用
make([]byte, 64*1024)而非make([]byte, 1024)减少 syscall 和切片重分配 - 避免频繁新建 cipher：复用
aes.Cipher实例，它本身是 goroutine-safe 的 - GCM 模式下，
Seal/Open的 nonce 长度必须严格为 12 字节才能触发快速路径
加密场景下 AES-NI 不起作用的典型原因
AES-NI 只加速核心轮函数（SubBytes、ShiftRows、MixColumns、AddRoundKey），不加速填充、认证标签计算、密钥扩展或 I/O。很多“慢”根本不是 AES 本身的问题。
例如：用 io.Copy 加密大文件却配了 4KB buffer，导致每 4KB 就调一次 Write → 每次都触发 GCM 的 tag 更新 → 非常慢；又或者密钥是 string 类型，每次调用都隐式转 []byte 触发额外 alloc。
- 密钥必须是
[]byte，别用string(key)临时转换 - 大文件流式加密时，buffer 至少设为 64KB，让 GCM 的内部缓冲区能批量处理
- 别在 hot path 里做 base64 编码：先加密到 []byte，再统一 encode，避免反复 malloc
- GC 压力大会拖慢：用
sync.Pool复用加密输出 buffer，尤其在高并发 HTTP handler 中
真正卡住性能的，往往不是 AES 指令有没有跑起来，而是你让 AES 在等内存、等锁、等 GC、等 syscall 返回。
