Go中间件中无法直接AES加密，因http.ResponseWriter一次性写入且不可重放，必须由handler主动构造数据后加密再写入；密钥长度须为16/24/32字节，IV需随机16字节并前置传输，填充须用PKCS#7。
为什么直接在 HTTP 中间件里加 AES 加密会失败
因为 Go 的 http.ResponseWriter 是一次性写入的，中间件拿到的 ResponseWriter 实际是包装后的接口，但标准库不保证其底层缓冲可重放或可截取。如果你在中间件中读取原始响应体（比如用 httptest.NewRecorder() 模拟），线上环境会因响应已写出而读不到内容，导致加密空数据或 panic。
真正可行的做法是让 handler 主动控制响应流程：先构造结构化数据，加密后再写入 response。不要试图“劫持”已有的 Write() 调用。
- 避免在中间件中调用
r.Body.Read()或尝试重读ResponseWriter - 统一响应结构必须前置定义，例如
type Resp struct { Code int `json:"code"` Data interface{} `json:"data"` } - 加密逻辑应放在 handler 返回前，而非中间件的
next.ServeHTTP()之后
如何用 crypto/aes 实现兼容前端的 CBC + PKCS7 加解密
前端（如 JavaScript 的 CryptoJS）默认使用 CBC 模式 + PKCS7 填充，而 Go 的 crypto/aes 默认只提供 PKCS5（本质与 PKCS7 在块大小为 8/16 字节时行为一致），但需手动补全——Go 不自动处理填充，必须自己实现 Pkcs7Pad 和 Pkcs7Unpad。
密钥和 IV 必须前后端完全一致，且 IV 应每次随机生成并随密文传输（不能固定）。常见错误是把 IV 硬编码成字符串再 []byte，结果长度不对（比如 UTF-8 编码后变长）。
立即学习“go语言免费学习笔记（深入）”；
- IV 必须是 16 字节，建议用
crypto/rand.Read(iv)生成，base64 后拼在密文前传给前端 - 加密前对 JSON 字符串做 PKCS7 补齐：目标长度 = ((len(src) + 15) / 16) * 16
- 解密时先 base64 解码，拆出前 16 字节为 IV，剩余为密文，再 AES-CBC 解密 + 去填充
// 示例：加密函数片段
func AesEncrypt(plaintext []byte, key, iv []byte) ([]byte, error) {
block, _ := aes.NewCipher(key)
if len(plaintext)%block.BlockSize() != 0 {
plaintext = Pkcs7Pad(plaintext, block.BlockSize())
}
mode := cipher.NewCBCEncrypter(block, iv)
ciphertext := make([]byte, len(plaintext))
mode.CryptBlocks(ciphertext, plaintext)
return ciphertext, nil
}gin 框架中如何安全注入加解密逻辑而不污染业务 handler
Gin 的 Context 本身不支持“返回值拦截”，所以不能靠 c.Next() 后取返回值。正确方式是封装一个响应辅助函数，比如 c.EncJSON(code int, data interface{})，并在初始化 router 时用 gin.Engine.Use() 注册一个预设密钥/配置的中间件，把加解密所需的密钥、是否启用等信息挂到 c.Keys 上。
- 不要在每个 handler 里重复写加密代码，而是扩展
*gin.Context方法（通过匿名字段或方法集绑定） - 解密请求参数应放在
Bind之前：从c.Request.Body读一次，解密后用bytes.NewReader替换c.Request.Body - 注意：
c.ShouldBindJSON()会消耗 body，解密必须在它之前完成，且只能做一次
遇到 “crypto/aes: invalid key size” 或 “cipher: message authentication failed” 怎么快速定位
前者基本等于你传进 aes.NewCipher() 的 key 长度不是 16/24/32 字节；后者大概率是解密时 IV 错了，或密文被截断、base64 解码失败、前后端填充方式不一致（比如前端用了 PKCS5Padding，Go 端却按 PKCS7 手动补了 0x08）。
- 打印
len(key)和len(iv)，确认分别是 16 和 16（AES-128） - 检查前端传来的密文是否完整——常见于 URL 查询参数中未正确 encode/decode + 和 / 字符
- 服务端解密前先校验密文长度是否为 16 的倍数，否则直接返回错误，避免 panic
最易忽略的是：同一个密钥在开发/测试/生产环境被不同方式加载（如环境变量里带空格、配置文件里用了 base64 但没解码），这类问题不会报错，但加解密结果始终不匹配。
