必须将defer放在next.ServeHTTP()调用之前，以确保其在函数返回前执行并准确捕获完整耗时；start需紧邻defer前赋值，且应结合包装ResponseWriter获取真实状态码与响应字节数。
中间件里 timing 记录必须放在 next.ServeHTTP 前
不是“越早越好”，而是必须紧挨着 next.ServeHTTP 调用之前注册 defer。因为 Go 的 defer 是函数返回前才执行，只有放在这里，才能确保 next 完全跑完（包括 Write、WriteHeader、甚至流式响应的 Body 读取完毕）。
常见错误是把 start := time.Now() 和 defer 都写在最开头，结果 panic 或提前 return 时 time.Since(start) 拿到的是不完整耗时；更隐蔽的坑是：如果用了 gzip、JWT 验证等中间件在它前面，那段逻辑也会被计入，但你可能只想看业务 handler 自身耗时——那就得把 timing 中间件往链路后挪。
-
start必须在defer之前赋值，且不能被后续逻辑覆盖或重置 - 别用
time.Now().Sub(start)，直接用time.Since(start)，精度一致且语义清晰 - 如果 handler 内部启动 goroutine 异步写响应（比如 SSE），
time.Since会低估真实延迟——这时得靠包装ResponseWriter+ 拦截Write才能捕获真正发送完成时间
为什么一定要包装 ResponseWriter 才能拿到真实状态码
标准 http.ResponseWriter 不暴露已写入的状态码，w.WriteHeader(404) 调用后，你从原始 w 上调用 w.Header().Get("Content-Length") 或查状态都拿不到。不包装就只能默认记 200，日志完全失真。
自定义结构体只需嵌入原 w，重写 WriteHeader 方法并保存状态码即可。注意：不要在 WriteHeader 里做耗时操作，否则阻塞响应；也不要漏掉对 Write 的拦截（大响应体写入本身也耗时）。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 结构体字段建议用
statusCode int而非指针，避免并发写冲突 - 别依赖
rw.(http.Hijacker)判断是否升级连接——没升级时类型断言失败，panic - 如果用了
gin.Context，可用c.Writer.Status()替代手动包装，但底层仍是同理
log.Printf 不适合生产，换 zerolog 或 zap
每次 log.Printf 都触发 GC 分配字符串、拼接、格式化，高频请求下 CPU 和内存压力明显。结构化日志库把字段预分配、复用 buffer、支持异步写，还能直接输出 JSON 方便 ELK 或 Loki 接入。
示例用 zerolog：先初始化全局 logger，中间件里直接 logger.Info().Str("path", r.URL.Path).Int("status", rw.statusCode).Dur("cost", time.Since(start)).Send()。字段名和类型固定，不依赖反射，性能差一个数量级。
- 避免在日志里传
interface{}或指针，比如log.Printf("%+v", req)—— 序列化开销大且易泄露敏感字段 - 不要给每个请求都开 goroutine 写日志，用
zerolog.NewConsoleWriter()或zap.NewProduction()内置的异步选项就够了 - 调试阶段可保留
log.Printf，但上线前必须切走，否则压测时日志吞吐会先拖垮服务
Gin 框架里用 c.Next() 而不是手写 next.ServeHTTP
Gin 的中间件签名是 gin.HandlerFunc，内部已封装好上下文传递和 panic 恢复。直接调 next.ServeHTTP(w, r) 会绕过 Gin 的 Context 生命周期，导致 c.Abort()、c.Error()、绑定参数失效，甚至 c.JSON() 报错。
正确写法是用 c.Next() 触发后续链路，耗时计算放在 c.Next() 后——这和标准库中间件里 next.ServeHTTP 的位置逻辑一致，只是 API 不同。
-
c.Next()之后才能安全读c.Writer.Status()和c.Writer.Size() - 别在
c.Next()前修改c.Request的 URL 或 Header，Gin 不保证这些变更会被下游看到 - 如果需要兼容标准库中间件（比如混用
net/http和gin），用gin.WrapH包装，而不是硬套函数签名
