Revel框架不自动加密请求参数，需业务层手动实现加解密；因框架定位是Web应用框架而非安全中间件，加密粒度、密钥管理、与CSRF/JWT等机制协同等均需开发者明确决策。
Revel 框架本身不提供请求参数（如 query、form、JSON body）的自动加密传输能力，它默认把参数当作明文处理。所谓“请求参数加密”，必须由业务层自行实现加解密逻辑，框架只负责透传原始数据。
为什么 Revel 不对请求参数加密
Revel 的设计定位是 Web 应用框架，不是安全中间件。它的职责边界在路由分发、控制器调用、Session 管理和模板渲染——所有输入都以原始 *http.Request 形式交给 Controller，加密/解密属于业务敏感逻辑，需开发者明确决策：
- 加密粒度不确定：是整个 body？某个字段？还是仅特定接口？框架无法预设
- 密钥生命周期难统一管理：请求级密钥、会话级密钥、服务级密钥策略差异大
- 与现有中间件（如 CSRF、JWT 验证）易冲突：比如先解密再验签，顺序错就全失效
- 调试和日志脱敏成本高：开发时需绕过加密，线上又得强制启用，配置易出错
如何在 Controller 中手动解密 query/form/body 参数
最直接的做法是在 Controller 方法开头做解密，把原始参数转为业务结构体。注意：必须在调用 c.Params.Get() 或 c.Params.All() 之前完成。
- 对
GET /api/user?id=xxx这类 query 参数：从c.Request.URL.Query()取值后解密 - 对
POST application/x-www-form-urlencoded：读c.Request.PostFormValue("data")再解密 - 对
POST application/json：用ioutil.ReadAll(c.Request.Body)获取原始字节，解密后再json.Unmarshal - 务必校验解密后数据完整性（如附带 HMAC 或使用 AES-GCM），防止篡改重放
示例（AES-GCM 解密 JSON body）：
func (c App) SecureEndpoint() revel.Result {
data, _ := io.ReadAll(c.Request.Body)
decrypted, err := aesGCMDecrypt(data, c.Session.Get("key"))
if err != nil {
return c.RenderError("invalid encrypted payload")
}
var req UserRequest
if err := json.Unmarshal(decrypted, &req); err != nil {
return c.RenderError("malformed payload")
}
// 后续业务逻辑
}避免在中间件里全局解密请求参数
有人尝试写一个 DecryptionFilter 放在 app.Init() 的 filter chain 里统一处理，但容易踩坑：
-
c.Request.Body是单次读取流，中间件读完后 Controller 再读就是空 —— 必须用io.NopCloser(bytes.NewBuffer(...))重置 Body - 无法区分哪些接口需要解密，硬编码会导致健康检查、静态资源等路径异常
- 错误处理难收敛：解密失败该返回 400？401？还是 500？不同场景语义不同
- 性能损耗不可控：每个请求都走一次 AES，QPS 高时 CPU 成瓶颈
更稳妥的做法是：只对明确标记的 Controller 方法做解密，其他保持原样。
真正该加密的其实是 Cookie 和通信链路
比起费力加密请求参数，合规和工程实践中优先级更高的是：
- 确保传输层用 HTTPS（强制
session.cookie.secure = true+ 反向代理正确转发X-Forwarded-Proto） - 对 Session Cookie 启用加密（见
app/init.go中aesCipher初始化），防窥探和篡改 - 敏感字段（如密码、token）永远不走 URL query，也不存入前端可控位置（localStorage、URL fragment）
- 若必须端到端加密，应由客户端 SDK 完成（如 WebCrypto API 加密后 base64 发送），服务端只负责解密验证，不暴露密钥
参数加密不是银弹。它增加复杂度，却不一定提升真实安全性——密钥泄露、IV 复用、解密逻辑绕过，任何一个环节出问题，整套机制就形同虚设。
