中间件中禁止直接调用c.JSON，应使用c.AbortWithStatusJSON()终止链并返回响应，且末尾必须加return；Timestamp字段须为int64类型并赋值time.Now().UnixMilli()。
中间件里不能直接调用 c.JSON 返回统一响应体
中间件的职责是预处理或后处理请求，不是替代 handler 做业务响应。如果在中间件里直接调用 c.JSON，会提前结束响应链，导致后续 handler 不执行——这常被误用于“全局鉴权失败返回 401”，但实际掩盖了 handler 是否该运行的问题。更严重的是，若 handler 后续又调用了 c.JSON，就会触发 http: multiple response.WriteHeader calls panic。
正确做法是：中间件只做 c.Abort() 或 c.AbortWithStatusJSON()，且必须确保这是该请求生命周期中唯一一次写响应。例如鉴权失败时：
- 用
c.AbortWithStatusJSON(http.StatusUnauthorized, response.Fail(401, "未登录")) - 之后必须跟
return，否则 handler 仍可能执行 - 不要在中间件里调用
response.Success——它默认是 200，与中间件语义冲突
response.Fail 和 c.AbortWithStatusJSON 必须配对使用
封装的 Fail 函数（如 Fail(c *gin.Context, httpStatus int, code int, msg string)）内部若只调用 c.JSON，就无法中断后续逻辑。必须显式用 c.AbortWithStatusJSON 替代，它会终止中间件链并写入响应。
常见错误写法：response.Fail(c, 400, 1001, "参数错误") 内部只是 c.JSON(400, ...)，没 Abort，handler 仍继续跑，可能查 DB、改状态、再 panic。
- 所有主动失败响应函数，末尾必须含
c.AbortWithStatusJSON(...)+return - HTTP 状态码（如 401）和业务码（如 1001）要分离：前者给网关看，后者给前端解析
- 别把
sql.ErrNoRows直接传给Fail的msg参数——字符串化后是 “sql: no rows in result set”，前端无法展示
想自动包装 handler 返回值？别用中间件劫持 Writer
有人尝试用自定义 responseWriterWrapper 拦截 c.Writer，读取原始 JSON 后再套一层统一结构。这看似“全自动”，实则问题密集：
- handler 调用
c.JSON(200, user)后，数据已序列化为字节流，再解析 JSON 易出错（如嵌套 map、time.Time 格式不一致） - 性能损耗明显：多一次反序列化 + 序列化，GC 压力翻倍
- 无法区分成功/失败场景——你没法从原始
{"id":1}推断该包进code:0还是code:500 - panic 捕获中间件（
gin.Recovery）和这种 wrapper 会互相干扰，日志和监控失真
真正可控的方式，是让每个 handler 显式调用 response.Success(c, data) 或 response.Fail400(c, "xxx")。这不是重复劳动，而是把响应语义落到代码行上。
Timestamp 字段必须用 time.Now().UnixMilli()，别用 Format
很多封装里加了 Timestamp string `json:"timestamp"` 并用 time.Now().Format("2006-01-02 15:04:05")，这会导致两个硬伤：
- 前端解析时间需额外适配字符串格式，不如毫秒时间戳通用
-
Format触发字符串分配，高频接口下 GC 频繁，pprof 里runtime.mallocgc占比飙升
正确字段定义是：Timestamp int64 `json:"timestamp"`，赋值用 time.Now().UnixMilli()。毫秒级精度够用，且无内存分配。
最容易被忽略的一点：所有响应函数（Success、Fail、OkWithData）都必须在函数末尾加 return。Gin 不会自动 return，漏掉它，哪怕只有一行日志或 defer，都可能造成双写响应或空指针 panic。
