Beego中间件不能直接修改响应体，必须在BeforeExec阶段包装ctx.ResponseWriter实现缓冲写入，并于Flush时解析并重写JSON响应；其他阶段或方式均不可靠。
Beego 中间件不能直接修改响应体，得靠 BeforeExec + ResponseWriter 包装
Beego 的中间件（Filter）本身不提供 ModifyResponse 这类钩子，ctx.ResponseWriter 是一个 http.ResponseWriter 接口，但默认实现（context.responseWriter）在写入后不可逆。想改响应内容，必须在 Controller 执行前、且响应尚未写出时，用包装器替换它。
常见错误是试图在 BeforeRouter 或 AfterStatic 阶段读取并重写 ctx.ResponseWriter——此时要么还没到写响应的时机，要么已经写完（比如静态文件已直出），根本拿不到原始 body。
- 唯一安全的拦截点是
beego.BeforeExec：路由已匹配、Controller 尚未执行，ctx.Input.Param()可用，且响应尚未开始写入 - 必须手动包装
ctx.ResponseWriter，实现自己的ResponseWriter，捕获Write()和WriteHeader()调用 - 不要用
io.ReadAll(ctx.ResponseWriter)——它不是io.Reader，无法直接读；你只能拦截写入过程 - 若 Controller 已调用
this.Ctx.WriteString()或this.Data["json"] = ...，响应体可能已被缓存或写出，此时再包装已晚
如何安全包装 ResponseWriter 并重写 JSON 响应体
核心是实现一个带缓冲的 ResponseWriter，在 Write() 时暂存字节，在 WriteHeader() 后或 Flush() 时做转换。下面是最简可行封装：
type bufferResponseWriter struct {
http.ResponseWriter
statusCode int
buf *bytes.Buffer
}
func (w *bufferResponseWriter) WriteHeader(statusCode int) {
w.statusCode = statusCode
w.ResponseWriter.WriteHeader(statusCode)
}
func (w *bufferResponseWriter) Write(b []byte) (int, error) {
if w.statusCode == 0 {
w.statusCode = 200
w.ResponseWriter.WriteHeader(200)
}
return w.buf.Write(b)
}
func (w *bufferResponseWriter) Flush() {
if w.statusCode >= 400 {
// 错误响应不处理
w.ResponseWriter.Write(w.buf.Bytes())
return
}
// 尝试解析为 map，添加字段
var data map[string]interface{}
if json.Unmarshal(w.buf.Bytes(), &data) == nil {
data["x-beego-modified"] = "true"
if modified, err := json.Marshal(data); err == nil {
w.ResponseWriter.Write(modified)
}
} else {
w.ResponseWriter.Write(w.buf.Bytes())
}
}
- 必须在
BeforeExec阶段注册，并确保只对目标路径（如/api/）生效，避免影响静态资源或登录页 -
Flush()是关键触发点：Beego 的 JSON 输出最终会调用它，这里才是你最后的修改机会 - 不要在
Write()中直接解析或修改——body 可能被分多次写入，需等全部收齐 - 注意 Content-Type：若原响应是
text/plain或application/xml，硬塞 JSON 字段会破坏格式，建议先检查ctx.ResponseWriter.Header().Get("Content-Type")
为什么 ctx.AbortWithStatusJSON 不适合用于“修改”已有响应
ctx.AbortWithStatusJSON() 是终止流程并立即写出新响应，它不会覆盖 Controller 已生成的内容，而是彻底跳过后续逻辑。如果你已在 Controller 中写了部分响应，再调这个函数，结果是两个响应头+两个响应体（HTTP 协议层面非法），客户端大概率收到截断或解析失败。
- 它适用于“拦截并拒绝”，比如权限不足时返回
{"error": "forbidden"}，而不是“补丁式增强” - 调用后
ctx.Next()不再执行，Controller 完全不会运行，所以你拿不到它生成的原始数据 - 若你真需要统一注入字段，应该让所有 Controller 都返回结构化数据（如
this.Data["json"] = map[string]interface{...}），然后在FinishRouter阶段统一处理——但 Beego 没有FinishRouter钩子，这条路走不通 - 更现实的做法是：把“响应增强”逻辑下沉到业务层，由 Controller 自己决定是否加字段，中间件只负责透传上下文（如用户 ID、请求 ID）
容易被忽略的坑：gzip、chunked 和并发写入
Beego 默认启用 gzip 压缩，而你的包装器如果没处理 WriteHeader() 后的压缩逻辑，会导致响应体被两次压缩或 header 冲突。同时，多个 goroutine 可能并发写入同一 ResponseWriter（比如日志中间件和响应包装器都注册在 BeforeExec），引发 panic。
- 务必检查
ctx.ResponseWriter.Header().Get("Content-Encoding")，如果是gzip，别碰原始 body 字节，改用gzip.NewWriter()包装后再写 - 用
sync.Once或原子操作确保包装器只被设置一次，避免重复包装导致嵌套错乱 - 不要在包装器里启动 goroutine 异步写响应——HTTP 响应必须同步完成，否则连接可能提前关闭
- 最稳妥的边界是：只对明确知道格式的路径（如
/api/v1/）且Content-Type: application/json的响应做修改，其余一律透传
