必须手动控制加解密时机，否则会破坏协议结构并导致中间件解析失败；密钥须经base64/hex解码后校验长度为32字节，nonce必须严格12字节且每次随机生成，加密输出固定为nonce+ciphertext+tag三段拼接，大消息应避免Seal阻塞而改用chacha20poly1305。
直接在Go微服务中对HTTP请求体或gRPC消息做AES-GCM加密，必须绕过框架默认的序列化流程，手动控制加解密时机；否则会破坏协议结构、导致中间件（如gin.Recovery、grpc.UnaryInterceptor）无法正确解析，甚至引发panic或静默失败。
为什么不能在gin.HandlerFunc或grpc.UnaryServerInterceptor里直接调用aes.NewCipher
因为aes.NewCipher只接受严格长度的[]byte：16/24/32字节缺一不可。而从环境变量读出的密钥字符串若含UTF-8多字节字符（比如中文注释、emoji），或未经hex/base64解码就直接[]byte("...")，实际长度就会错——这不是“密钥强度不够”，是Go运行时直接panic: crypto/aes: invalid key size。
- 密钥必须从
os.Getenv("AES_KEY")读取后，先用base64.StdEncoding.DecodeString或hex.DecodeString解码，再校验len(key) == 32 - 绝不能用
sha256.Sum256([]byte(...)).Sum(nil)直接转切片——它返回的是带固定底层数组的结构体，强制转换后类型不匹配，aes.NewCipher仍会panic - 更安全的做法是：密钥由KMS（如Vault）下发，用
syscall.Mlock锁住内存页，防swap泄露
cipher.NewGCM返回值必须和nonce长度严格对齐
GCM标准规定nonce长度为12字节，gcm.NonceSize()返回值必须等于12；但如果你用make([]byte, 16)生成nonce，或写入文件时误加length prefix，解密时io.ReadFull读出的前12字节就不是原始nonce，gcm.Open会返回cipher.ErrInvalidLength或静默返回空切片——这不是逻辑bug，是输入数据结构本身已损坏。
- 每次加密都调用
nonce := make([]byte, 12)，再用io.ReadFull(rand.Reader, nonce)填充（必须检查error） - 加密输出固定为：
[12-byte nonce][ciphertext][16-byte tag]，三段拼接后base64编码传给下游 - 解密时先
io.ReadFull(r, nonce)读前12字节，剩余全部传给gcm.Open；别用r.Read+len判断，容易读不全
如何在gRPC流式场景下避免Seal阻塞整个stream
cipher.AEAD.Seal不支持流式加密，它把整个明文当单一块处理。如果gRPC message体积大（比如上传二进制附件），直接Seal会导致内存暴涨甚至OOM。强行分块加密又得自己管理每块nonce唯一性，极易复用——这是生产事故高发区。
- 小消息（Seal，把完整message当明文，nonce放header或metadata传输
- 大消息（>1MB）：改用
chacha20poly1305（标准库也支持），它对长流更友好，且nonce长度也是12字节，兼容现有逻辑 - 绝对不要在
StreamServerInterceptor里对RecvMsg返回的interface{}直接Seal——它可能是未反序列化的原始字节，也可能是已解包的struct，类型不确定，panic风险极高
真正难的不是写对Seal和Open，而是确保密钥生命周期、nonce生成路径、数据拼接格式这三者在所有服务节点上完全一致；任意一个环节被CI/CD脚本、Docker镜像层或运维配置覆盖，整条链路就 silently fail。
