必须补位。AES块大小固定为16字节，明文非16倍数时CryptBlocks会panic；需用PKCS#7补位（含整除时补16字节），解密后须校验补位值。
Go 用 crypto/aes 加密前必须补位吗？
必须。AES 是分组密码，块大小固定为 16 字节，明文长度不是 16 的倍数时，aes.NewCipher 本身不报错，但 cipher.NewCBCEncrypter 或 cipher.NewCFBEncrypter 在调用 crypter.CryptBlocks 时会 panic：crypto/cipher: input not full block。
常见做法是 PKCS#7 补位（对 AES 来说等同于 PKCS#5）：
- 补位字节值 = 补的字节数（如缺 3 字节，则末尾加
\x03\x03\x03） - 若原文长度刚好是 16 倍数，仍需补满 16 字节（即加
\x10重复 16 次） - 解密后必须校验补位值，防止篡改或错误截断
如何安全生成和管理 AES 密钥与 IV？
密钥不能硬编码、不能用字符串直接转 []byte（比如 []byte("mykey123")），而应通过密钥派生或安全随机生成；IV 必须每次加密唯一，且不可复用（尤其 CBC 模式）。
推荐做法：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 密钥：用
crypto/rand.Read生成 32 字节（AES-256）或 16 字节（AES-128），存于环境变量或 KMS，绝不写死 - IV：每次加密前生成 16 字节随机值，和密文一起输出（如
iv + ciphertext），解密时先切出前 16 字节 - 不要用时间戳、计数器或固定值当 IV —— CBC 下会导致相同明文产生相同密文前缀，泄露模式
CBC 和 GCM 模式该怎么选？
CBC 只提供机密性，不防篡改；GCM 同时提供加密+认证（AEAD），是现代首选，但 Go 标准库的 crypto/cipher.AEAD 接口要求额外 nonce（类似 IV），且对 nonce 重用极度敏感（导致密钥泄露）。
实操建议：
- 新项目无条件选
crypto/aes+crypto/cipher.NewGCM - GCM 的 nonce 长度通常设 12 字节（Go 默认），用
crypto/rand.Read生成，和密文一起存储 - 避免手写 CBC + HMAC 组合 —— 容易出错（比如 HMAC 算的是密文还是明文？顺序是否恒定？）
- 如果必须兼容旧 CBC 接口，至少加上独立的 HMAC-SHA256 校验，且先验证再解密（“encrypt-then-MAC”）
为什么解密后得到乱码或 panic？
最常见三个原因：密钥/IV 不匹配、补位逻辑不一致、模式参数传错（比如加密用 CBC，解密用了 CFB）。
快速排查点：
- 检查加密和解密用的密钥是否完全相同（
len(k)==32且每个字节一致，注意空格和编码） - 确认 IV 是从密文开头正确切出来的（CBC/GCM 都要，别漏掉或切错长度）
- 解密后必须调用补位去除函数，且校验补位值是否在
1–16范围内 —— 否则可能是密文被截断或密钥错误 - GCM 解密失败时不会返回错误，而是返回零长度明文 +
nilerror；必须用aead.Open的返回值判断是否成功
补位和 nonce 管理是 AES 实现里最容易被跳过的细节，但恰恰是安全性和稳定性的分水岭。哪怕只差一个字节的 IV 或补位校验，生产环境就可能静默失败或被绕过。
