本文首先梳理几个关键注意事项，帮助新手避开常见陷阱，同时让有经验的开发者巩固知识。Go语言中的AES加密看似简单，但实际编码时，许多细微之处容易埋下隐患。事实上，不少线上故障的根本原因并非算法本身，而是密钥、初始化向量(IV)、填充方式等细节未能正确对齐。

### 密钥长度不匹配将直接引发panic，切勿“差不多”就行 `aes.NewCipher` 不会跟你商量。传给它一个 15 字节或 17 字节的密钥，它会立刻抛出一个 `crypto/aes: invalid key size` 的 panic。Go 不做截断、不补零、不提示“建议用 16”，它只认死理：`len(key)` 必须是 16、24 或 32。 - 硬编码测试时，建议使用 `[]byte("1234567890123456")` 这类显式写满的字符串，确保长度精确无误。注意，字符串中不能包含隐藏的空格、换行符或BOM标记。 - 从环境变量或配置文件读取密钥时，不要用 `len(key)` 检查字符串长度，因为这会错误计数（尤其是包含中文或emoji时）。必须使用 `len([]byte(key))` 获取真实的字节数。 - 生产环境更推荐采用派生密钥：使用 `sha256.Sum256([]byte(raw)).[0:32]` 生成一个稳定的32字节密钥，从此告别手工计数错误的风险。 ### CBC模式下出现乱码？先检查IV和填充是否正确 CBC 解密失败有个特点：它几乎从不报错，只会默默地输出一堆乱码。问题大概率出在三处：IV 切片位置错误、PKCS#7 填充未校验、明文末尾被截断。 - 密文开头必须是16字节的IV。解密时，应使用 `ciphertext[:aes.BlockSize()]` 提取IV，剩余部分才是真正的密文。这个顺序不可颠倒，否则会完全混乱。 - 填充必须严格遵循PKCS#7规则。例如，若原始明文长度 mod 16 等于5，则需要补11个 `0x0b`；如果恰好被16整除，则需要额外补充16个 `0x10`。少一个字节都不行。 - 解密后不能简单用 `orig[:len(orig)-pad]` 截断。正确的做法是：先读取最后一个字节，记为 `n := orig[len(orig)-1]`，然后验证最后 `n` 个字节是否全部等于 `n`。如果不相等，说明数据可能被篡改，或者IV使用错误。这才是正确的处理方式。 ### GCM模式并非“更简单”，而是更容易陷入nonce重用的陷阱 `cipher.NewGCM` 返回的 `AEAD` 接口，确实省去了手动处理填充和 IV 的麻烦，但它引入了一个更致命的陷阱：nonce 重用。nonce 一旦重用，后果比 CBC 的 IV 复用严重得多——攻击者可以直接恢复密钥。 - `nonce` 长度固定为12字节（Go的默认行为），不是16，也不能随意设置。 - 必须使用 `crypto/rand.Read(nonce)` 生成，且每次加密都必须生成新的nonce。不要为了省事而拼接时间戳、使用计数器，更不要重复使用nonce。这是底线。 - 密文的结构为 `nonce + ciphertext + tag`（tag默认16字节）。解密前，必须先将最后16字节切出来作为 `tag`，再传给 `aead.Open`。顺序搞错，解密必然失败。 - `aead.Open` 返回 `cipher.AEADDecryptError` 表示认证失败，此时绝不能忽略该错误而继续使用解密结果。这是GCM模式的安全基石。 ### 切勿使用ECB模式，即使仅用于“临时混淆” ECB 看起来最“简单”：不用 IV、不用填充、直接 `block.Encrypt` 循环调用。但它有一个致命缺陷：相同的明文块永远输出相同的密文块。比如，日志里反复出现的 `"status:success"`，会被识别为固定的密文模式，这跟裸奔没什么区别。立即学习“go语言免费学习笔记（深入）”； - 即使只是“临时混淆”，也请至少使用CBC + 随机IV。将IV明文附在密文前，不会增加风险，但能彻底打破ECB的确定性模式。 - 千万不要用 `key[:16]` 作为IV。这相当于将密钥的一部分暴露给攻击者，而且完全丧失了随机性。 - 流式加密大文件时，CBC仍需完整的填充，而GCM更适合。但无论使用哪种模式，`io.ReadFull(rand.Reader, iv)` 比 `rand.Read(iv)` 更安全，可以确保IV被完整读取，避免因读取不足而出错。 实际加解密逻辑中最薄弱的环节，往往不是算法本身，而是密钥、IV、tag这些边界的切割操作。多一个字节、少一个字节、切错位置，都会导致解密变成“看似成功”的乱码。动手编写代码前，请先仔细检查那几行切片和长度校验的代码，它们才是真正的胜负关键。