cipher.newcbcdecrypter报“invalid buffer overlap”需分配新切片避免src/dst重叠，解密后必须手动pkcs#7去填充，且decrypter不可复用。
cipher.NewCBCDecrypter 调用失败，十有八九是内存重叠或填充没处理——Go 的 cipher 包不做自动填充/去填充，也不允许原地解密，这两点必须手动兜底。
调用 cipher.NewCBCDecrypter 时 panic “invalid buffer overlap” 怎么修
这是 Go 标准库的硬性安全检查：解密目标切片（dst）和源密文切片（src）不能有任何内存重叠，哪怕只差一个字节也不行。
常见错误写法：decrypter.CryptBlocks(ciphertext, ciphertext) —— 想原地覆盖，但 Go 直接 panic。
- 正确做法：分配新切片，长度与密文一致：
plaintext := make([]byte, len(ciphertext)) - 再调用：
decrypter.CryptBlocks(plaintext, ciphertext) - 如果必须复用内存（比如内存受限场景），先
copy(tempBuf, ciphertext)，再把tempBuf传给CryptBlocks - 注意：IV 必须从密文头部正确截取，且不能参与
CryptBlocks的 dst/src 重叠判断（它只是参数，不参与写入）
cipher.NewCBCDecrypter 解密后末尾全是 \x07 或乱码
这不是算法错，是 PKCS#7 填充没去掉。AES-CBC 本身只负责块加解密，填充逻辑完全由你负责。
- 解密后必须显式调用去填充函数，例如用
golang.org/x/crypto/pkcs7：pkcs7.Unpad(plaintext, aes.BlockSize) - 自己手写也行，但要注意：最后一个字节值
n表示末尾n字节都是填充，且必须全部等于n；否则说明密文被篡改或密钥/IV 错了 - 别在去填充前做
string(plaintext)转换，二进制数据转 string 会截断或乱码，应先去填充再转 - 如果密文长度不是
aes.BlockSize（16）的整数倍，CryptBlocks不会报错，但结果必然错——务必提前校验：len(ciphertext)%aes.BlockSize == 0
HTTP 请求中解密 query 或 body 参数，r.Body 读空了怎么办
根本原因是 ParseForm、PostFormValue 或 json.Decode 都会消费 r.Body 一次，之后再 io.ReadAll(r.Body) 就只能拿到空 slice 或 io.EOF。
- 解密 query 参数：用
r.URL.RawQuery拿原始字符串，再手动解析data=xxx，保留 URL 编码（如%3D），最后用base64.StdEncoding.DecodeString解码 - 解密 POST body：跳过
ParseForm和json.Decode，直接io.ReadAll(r.Body)→ base64 解码 → AES 解密 - 如果业务同时需要表单字段和加密字段，建议统一走 JSON body，并约定加密字段名（如
"encrypted_payload"），避免混用解析方式
为什么 cipher.NewCBCDecrypter 返回的 decrypter 不能复用
它不是线程安全的，内部维护状态（比如 CBC 的链式依赖），并发调用同一实例会导致解密错乱，甚至 panic。
- 每次解密都应新建 decrypter：
cipher.NewCBCDecrypter(block, iv) - 不要缓存或全局复用该对象；
block（来自aes.NewCipher）可以复用，它是只读的 - IV 必须每次不同（尤其用于加密时），但解密时必须用加密时那个 exact IV；若 IV 是固定值（如硬编码），那它就不是安全的 CBC，仅适用于测试
- 性能上，
NewCBCDecrypter开销极小，不用省；真正要优化的是密钥派生或大文件分块解密逻辑
CryptBlocks 就永远返回一堆无法解释的字节。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
