Go日志中间件必须包装http.ResponseWriter并置于链末端，才能准确获取状态码、响应大小及trace_id；否则会漏记熔断、状态码为0、丢失panic日志。
Go 日志中间件不能只在 handler 里 log.Printf 就完事——它必须包装 http.ResponseWriter 才能拿到真实状态码和响应大小，且必须放在中间件链末端（TraceMiddleware → CircuitBreaker → LoggingMiddleware → handler），否则会漏记熔断、丢失 trace ID 或写入 0 状态码。
为什么直接用 log.Printf 不行
单纯在业务 handler 里打日志，拿不到响应体大小、无法确认最终状态码（比如 client 断连后 w.WriteHeader(200) 实际没发出去）、耗时计算也受 panic 干扰。更关键的是：它不感知中间件链上下文，r.Context().Value("trace_id") 在未透传时就是 nil。
- 状态码可能始终为 0：因为
WriteHeader没被显式调用，Go 默认返回 200，但你无法在ServeHTTP返回后读取它 - 响应大小无法统计：
Write调用可能被中间件或 handler 提前终止 - panic 会导致日志完全丢失：defer 里的日志语句根本不会执行
必须用 statusRecorder 包装 ResponseWriter
定义一个结构体嵌入 http.ResponseWriter，重写 WriteHeader 和 Write 方法，缓存状态码、累加字节数：
type statusRecorder struct {
http.ResponseWriter
status int
size int
}
func (r *statusRecorder) WriteHeader(code int) {
r.status = code
r.ResponseWriter.WriteHeader(code)
}
func (r *statusRecorder) Write(b []byte) (int, error) {
if r.status == 0 {
r.status = http.StatusOK
}
n, err := r.ResponseWriter.Write(b)
r.size += n
return n, err
}
- 务必在
next.ServeHTTP(w, r)之后读取r.status和r.size，此时值才确定 - 别在
WriteHeader里做耗时操作，避免阻塞响应流 - 如果 handler panic，
defer recover()必须加在中间件最外层，否则日志逻辑中断
中间件链顺序不能错
日志中间件位置错误是线上最常见的日志缺失原因：
立即学习“go语言免费学习笔记（深入）”；
- 放在
CircuitBreaker前：熔断拦截后next.ServeHTTP()根本不执行，日志里看不到“503 Service Unavailable” - 放在
TraceMiddleware前：r.Context().Value("trace_id")可能为空，或记录到的是上层代理的 trace，不是本服务生成的 - 放在
auth或rate limit后没问题，但必须确保这些中间件已正确将必要字段写入 context
生产环境还要注意采样和结构化
高频请求全量打日志会压垮磁盘和日志采集链路：
- 对健康检查路径（如
/healthz）或 200 成功请求做低频采样，比如每 1000 条记 1 条 - 用
logrus或zap输出 JSON，字段固定为method、path、status、size、duration_ms、trace_id、remote_addr - 绝对不要在日志中间件里解析
r.Body（会 consume body，后续 handler 读不到）
最易被忽略的一点：time.Since(start) 必须在 next.ServeHTTP() 之后立刻计算，且不能依赖 defer ——panic 会让 defer 执行，但此时 status 还没写入，日志里 status 字段永远是 0。
