gin.Logger() 无法准确统计状态码异常分布，因其依赖 c.Writer.Status() 获取状态码，而该值在 panic 或 Abort() 后未更新，导致日志中大量误记为 200；必须包装 ResponseWriter 并重写 WriteHeader() 和 Write() 才能捕获真实状态码。
为什么 gin.Logger() 不能用于统计状态码异常分布
因为 gin.Logger() 只在请求结束时调用 c.Writer.Status()，而这个值在 panic 或中间件提前 c.Abort() 后可能未被正确写入——比如 Recovery 中间件捕获 panic 后调用 c.AbortWithStatus(500)，但此时 c.Writer 的底层状态码字段尚未更新，c.Writer.Status() 仍返回 0 或旧值。日志里大量出现 “200” 却实际返回了 500，就是这个原因。
必须包装 ResponseWriter 才能拿到真实状态码
标准 http.ResponseWriter 不暴露已写入的状态码；w.WriteHeader(500) 调用后，原始响应器上查不到该值。不包装就只能默认记 200，统计完全失真。
- 自定义结构体只需嵌入原
c.Writer，重写WriteHeader()并保存statusCode字段 - 字段类型用
int（非指针），避免并发写冲突 - 别在
WriteHeader()里做耗时操作，否则阻塞整个响应流 - 记得同时拦截
Write()：大响应体写入本身也耗时，且某些 handler 可能不显式调用WriteHeader()，靠Write()触发隐式状态码（如 200）
如何在中间件中安全聚合异常状态码（4xx/5xx）
状态码统计不是简单累加，得区分“业务主动返回”和“框架兜底返回”。比如 JWT 验证失败应记为 401，但若鉴权中间件 panic 了，Recovery 会兜底返回 500——这两类异常来源不同，修复优先级也不同。
- 注册顺序必须是：
Recovery()→ 鉴权中间件 → 状态码采集中间件 → 业务 handler - 采集中间件里用
c.Get("status_code")（由前序中间件设置）+w.statusCode（包装器捕获）双源校验，避免 Recovery 未覆盖时取到 0 - 对 499（Client Closed Request）这类 Nginx 自定义码，需从
c.Request.Header.Get("X-Request-ID")关联 access log 才能归因，中间件内无法单独识别 - 高频接口建议用原子计数器（如
atomic.AddInt64(&counter4xx, 1)）而非 map + mutex，避免锁竞争
响应体内容要不要一起采样？什么时候该关
记录响应体能帮你快速定位 500 错误的具体错误信息（比如 JSON 中的 "error": "timeout"），但生产环境必须可控开关——它吃内存、拖慢响应、还可能泄露敏感字段。
- 仅对
c.Request.Method == "POST" || c.Request.Method == "PUT"且c.Writer.Status() >= 400的请求开启响应体缓存 - 用
bytes.Buffer限制最大缓冲长度（如 2KB），超长直接截断并标记"body_truncated:true" - 绝对不要在中间件里调用
c.ShouldBindJSON()或读c.Request.Body——会清空 body，导致后续 handler 绑定失败 - 调试阶段可用
gin.Mode() == gin.DebugMode控制，线上通过配置项（如环境变量LOG_RESPONSE_BODY=off）动态关闭
WriteHeader() 调用前 panic ——这些场景下，你自定义的包装器甚至收不到 WriteHeader 调用，statusCode 字段仍是初始值 0。这时只能靠访问日志（access log）与错误日志（error log）交叉比对，而不是依赖单一中间件。 
