Revel框架无法直接在RenderJSON中加密响应，因响应流已开始写入；必须自定义EncryptedJSON Result类型，在Apply方法中完成JSON序列化、AES加密、设置响应头及写入密文全流程。
Revel框架本身不内置AES加解密中间件，也不能直接在Result层自动加密响应体。想让所有API返回的数据走AES加密，必须手动拦截、序列化、加密、再包装HTTP响应——而且得避开Revel默认的JSON渲染逻辑。
为什么不能直接用RenderJSON或JSON返回值
Revel的JSON和RenderJSON方法会直接调用json.Marshal并写入Response.Out，此时响应头已发、状态码已定、Body流已开始写入。你没法在这个阶段“中途插一脚”把原始JSON再套一层AES密文。
- 试图在
Finish()或InterceptFunc里重写Response.Out会导致http: multiple response.WriteHeader calls错误 -
RenderJSON返回的是revel.Result接口，不是可修改的字节流 - 如果用
response.Out.Write()强行覆盖，会破坏HTTP chunked编码或Content-Length计算
推荐做法：自定义Result类型封装AES加密逻辑
继承revel.Result，在Apply方法中完成序列化 → AES加密 → 设置响应头 → 写入密文的全流程。这是唯一能与Revel生命周期对齐、又不破坏HTTP语义的方式。
- 密钥和IV必须从配置读取，不要硬编码；建议用
revel.Config.StringDefault("aes.key", "") - AES模式选
CBC或GCM；GCM需额外处理认证标签（Nonce+Tag），但更安全 - 加密前先
json.Marshal原始数据，再用crypto/aes和crypto/cipher标准库加密 - 响应头必须显式设置
Content-Type: application/octet-stream或自定义类型（如application/vnd.encrypted+json），避免前端误解析
示例关键片段：
type EncryptedJSON struct {
Data interface{}
}
func (r *EncryptedJSON) Apply(req *revel.Request, resp *revel.Response) revel.Result {
raw, _ := json.Marshal(r.Data)
key := []byte(revel.Config.StringDefault("aes.key", "16-byte-key-12345"))
iv := make([]byte, aes.BlockSize)
block, _ := aes.NewCipher(key)
mode := cipher.NewCBCEncrypter(block, iv)
encrypted := make([]byte, len(raw))
mode.CryptBlocks(encrypted, raw)
resp.Out.Header().Set("Content-Type", "application/octet-stream")
resp.Out.WriteHeader(200)
resp.Out.Write(encrypted)
return nil
}
前端如何解密？注意密钥分发和IV一致性
服务端用CBC模式时，IV必须每次随机生成并随密文一起传给前端（比如Base64编码后放X-IV响应头）；GCM模式则需同时传递Nonce和AuthTag。前端JS用Web Crypto API解密时，IV/Nonce不能复用，否则安全性坍塌。
- 别用
localStorage存AES密钥——它等同于明文暴露 - 密钥应由登录成功后服务端动态下发（例如JWT payload里带加密后的AES密钥）
- 前端解密失败常见原因：
ArrayBuffer长度不对、IV未正确Uint8Array.from(atob(...), c => c.charCodeAt(0))还原、GCM模式漏传tag - Revel中间件里若启用
GzipFilter，必须关掉——压缩后再加密会极大削弱AES的扩散性，且解密后还需再解压，链路太脆
最易被忽略的一点：Revel的Validation.ErrorMap和Flash消息也走同一套响应流程。如果你只对*EncryptedJSON做加密，而错误响应仍走RenderJSON，就会出现部分接口加密、部分明文的混搭状态——前端无法统一处理，调试时容易误判为“加密没生效”。要么全量接管，要么明确划分加密/非加密接口域。
