Go语言框架实现接口响应的统一加密与解密传输-Golang-PHP中文网

go中间件中无法直接aes加密，因http.responsewriter一次性写入且不可重放，必须由handler主动构造数据后加密再写入；密钥长度须为16/24/32字节，iv需随机16字节并前置传输，填充须用pkcs#7。

go语言框架实现接口响应的统一加密与解密传输

为什么直接在 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 编码后变长）。

Gin框架 1.9.0

Gin框架 1.9.0版本源码包下载，版本号 1.9.0，适合需要 sonic JSON 支持、路由修复和内容协商改进的 Go Web 开发场景。

下载

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，解密必须在它之前完成，且只能做一次