中间件无法直接加密响应体，因echo中间件在writeheader和write之后执行，而aes-gcm要求nonce提前写入响应头、认证标签最后追加；需替换responsewriter实现流式加密，首次write写header+nonce，后续write交由aesgcm.encryptwriter处理。
中间件无法直接加密响应体的原因
因为 Echo 的中间件默认在 WriteHeader 和 Write 之后才执行，而 AES-GCM 等认证加密要求：nonce 必须唯一且提前写入响应头，认证标签（16 字节）必须最后追加。中间件看到的 ResponseWriter 是框架封装后的缓冲写入器，所有响应体已被读入内存——你没法边流式读原始数据、边加密、边发包。
必须替换 ResponseWriter 实现流式加密
核心思路是：在中间件中用自定义 ResponseWriter 替换原生对象，第一次调用 Write 时写 header + nonce，后续所有 Write 转发给 aesgcm.EncryptWriter（需自己实现或基于 crypto/aes + crypto/cipher 构建）。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 不要在 handler 里调用
c.Response().Writer.Write()，否则会绕过你的加密 writer - nonce 必须每次请求随机生成（用
crypto/rand.Read），不能复用，否则破坏安全性 - 响应头中需显式设置
Content-Encoding: aesgcm（非标准，但便于调试识别） - 避免对
Content-Type: text/event-stream或分块传输的响应做加密，这类场景需额外处理 flush 逻辑
微信/支付宝回调验签中间件不能复用为加密中间件
验签中间件和响应加密中间件职责完全不同：前者读原始 Body 做签名比对，后者改写输出流。二者可共存，但不能合并。常见错误包括：
- 在验签中间件里调用
io.ReadAll(c.Request().Body)后，再试图在加密中间件里读Body→ 报错http: read on closed response body - 把加密逻辑塞进验签中间件的
return next(c)之后 → 加密被跳过，因为 handler 已经写完响应 - 对
echo.HTTPError类错误响应也强制加密 → 微信等平台不认加密后的fail字符串，导致重试风暴
实际部署时最易忽略的点
加密中间件生效的前提是它必须在所有业务 handler 执行前注册，并且不能被 c.Response().Writer 的任何直接操作绕过。尤其注意：
-
echo.File()和echo.Stream()默认不走中间件链，加密中间件对其完全无效 - 使用
c.JSON()、c.XML()等快捷方法时，它们内部调用的是WriteHeader+Write，所以能被加密 writer 拦截；但c.Blob()若传入预加密字节，则会跳过加密流程 - HTTP/2 的头部压缩可能干扰 nonce 传递，建议在加密后手动禁用
Content-Encoding头以外的所有编码头
