需确保解密输入长度为16字节整数倍，正确分离IV、去除PKCS#7填充，并用GCM等带认证模式替代CBC，同时校验解密后数据完整性。
解密时 panic: crypto/cipher: invalid buffer size 怎么修
这是 crypto/cipher 包对底层块加密（如 AES）的硬性校验：输入长度不是块大小（16 字节）的整数倍。常见于直接拿 base64 解码后的字节去调 crypter.Decrypt()，却没处理 PKCS#7 填充或忽略 IV 长度。
- 确认你传给
Decrypt()的字节切片长度 = 密文长度 − IV 长度（若 IV 附在密文前），且该结果必须是 16 的倍数 - 如果密文带填充（比如用
pkcs7.Padding加密过），解密后要手动去除填充；别指望Decrypt()自动做这事 - 用
bytes.Equal(ciphertext[:aes.BlockSize], iv)检查前 16 字节是否真为 IV，避免“以为有 IV 实则没有”导致后续错位
key 不匹配时为什么只报 cipher: incorrect key size 而不是“密钥错误”
cipher: incorrect key size 是 Go 标准库在初始化 aes.NewCipher() 时抛的错误，它只校验 key 长度（16/24/32 字节），不验证内容是否与加密时一致。真正密钥不匹配的表现是解密后得到乱码、JSON 解析失败、或校验和不通过——此时不会 panic，而是静默失败。
- 别依赖错误信息判断“是不是密钥错了”，
incorrect key size只说明你传了 17 字节或 nil，跟“密钥值不对”无关 - 生产环境务必在加密/解密前后加消息认证（如
hmac或crypto/aes.(*cipher).NewGCM()），否则攻击者篡改密文你也无法察觉 - 密钥建议用
sha256.Sum256对原始字符串哈希后再截取 32 字节，避免直接用短口令当 AES-256 key
用 crypto/aes + crypto/cipher.NewCBCDecrypter 解密失败却不报错
CBC 模式下，只要输入长度合法、key 和 IV 类型正确，Decrypt() 就会执行并返回无 error 的 []byte——哪怕密钥完全错误、IV 被篡改、或者密文被截断。结果就是解出来一堆不可读字节，string(decrypted) 看着像乱码，json.Unmarshal() 报 invalid character，但没人告诉你根源是解密失败。
- 永远不要跳过解密后的内容校验：比如开头加固定 magic bytes（
[]byte{0x47, 0x4f, 0x4c, 0x41}），或结尾附 CRC32 - 避免用 CBC + PKCS#7 处理敏感数据；优先选
aes.NewGCM()，它把认证和加密绑在一起，解密失败直接返回 error - IV 必须每次加密都随机生成并随密文传输，但别用
rand.Int()——用crypto/rand.Read(iv)，否则 IV 可预测会导致 CBC 被攻破
error 是 nil 但 decrypted == nil 或 len(decrypted) == 0
这通常发生在你传了空密文、或密文被意外截断（比如 HTTP body 未完整读取）、或用了错误的 block cipher 实例（比如用 aes.NewCipher(key) 得到的 cipher 传给了 cipher.NewCFBDecrypter）。Go 不会在 Decrypt 前校验输入有效性，而是直接操作底层数组。
立即学习“go语言免费学习笔记（深入）”；
- 检查密文长度：AES-CBC 要求 ≥ 16 字节（至少一个块），AES-GCM 要求 ≥ 12 字节（nonce）+ 16（tag）
- 确保
decrypted切片已预分配足够空间：decrypted := make([]byte, len(ciphertext))，别传nil或太小的 slice - 如果用的是 stream cipher（如 CFB、OFB），注意它们不校验密文完整性，解密失败也不会报错，只能靠业务层校验
