最轻量可控的统一响应方式是handler存结构体到ctx.Values()，中间件检查后调用ctx.JSON()输出；禁用ctx.Recorder().Body()因其非生产就绪、易引发竞态与数据丢失。
直接在 ctx.Next() 后读取 ctx.Values().Get("json_result") 并返回，是最轻量、最可控的统一响应方式；别用 ctx.Recorder().Body() 截获响应体——它不是为生产设计的。
中间件里怎么安全地注入统一 JSON 响应
核心逻辑是「让 handler 自己决定返回什么，中间件只负责兜底包装」。handler 处理完后把结构体存进 ctx.Values()，中间件检查存在性并输出。这比劫持响应体更稳定，也避免了 panic 捕获时机错位的问题。
- 必须调用
ctx.Next()让后续 handler 先执行，否则ctx.Values()为空 - 存值时用明确 key，比如
ctx.Values().Set("json_result", result)，避免用字符串字面量硬编码多次 - 不要在 handler 里直接
ctx.JSON()，否则中间件还会再执行一次，造成重复写响应 - 如果 handler panic，需靠 recover 中间件提前设好 error 结构，例如
ctx.Values().Set("json_result", map[string]interface{}{"code": -1, "msg": "server error"})
为什么不能用 ctx.Recorder().Body() 改写响应
ctx.Recorder().Body() 是 Iris 为单元测试模拟响应体设计的，内部依赖 io.ReadWriter 缓冲，在高并发或流式响应（如 SSE、文件下载）场景下容易丢数据、乱码或 panic。生产环境一旦启用，会触发不可预测的竞态行为。
- 它绕过了 Iris 的 HTTP writer 生命周期管理，
ctx.StatusCode()和ctx.ContentType()可能不同步 - 若 handler 已调用
ctx.ResponseWriter().WriteHeader()，再读Body()会返回空或截断内容 - 日志中间件若在它之后执行，记录的 response size 会严重失真
状态码和 JSON 必须由同一处控制
常见错误是 handler 设了 ctx.StatusCode(iris.StatusCreated)，中间件又无条件 ctx.JSON(iris.StatusOK, ...)，最终状态码变成 200。统一格式的前提是「状态码 + 数据结构」原子化输出。
- 推荐在中间件里统一调用
ctx.JSON(statusCode, data)，其中statusCode从ctx.Values().Get("status_code")获取，默认为iris.StatusOK - handler 写入
json_result时，一并写入status_code，例如：ctx.Values().Set("status_code", iris.StatusCreated) - error 场景下，recover 中间件应设
status_code为iris.StatusInternalServerError或对应业务码，不能只改 data
嵌套结构、时间、Decimal 怎么自动序列化
Iris 默认用 Go 标准库 json.Marshal，不处理 time.Time、big.Int、decimal.Decimal 等类型。直接传入会导致 json: unsupported type: time.Time 错误。
- 全局注册自定义 JSON marshaler：在
app.Run()前调用iris.JSONConfig{Indent: " ", Unmarshal: json.Unmarshal, Marshal: customJSONMarshal} - 更简单的是在 handler 里手动转：用
json.MarshalIndent+bytes.NewReader构造io.Reader，再调ctx.Response().Write，但会绕过中间件 - 实际项目中，建议所有返回结构体字段用
string存时间（ISO8601）、float64存 Decimal，并在 struct tag 加json:",omitempty"控制空值
真正难的不是写中间件，而是让每个 handler 都记得存 json_result 和 status_code ——最好用模板代码生成器或 linter 规则强制校验。
