正确做法是包装responsewriter，重写writeheader()和write()，在最后一次write()或writeheader()后记录时间；避免defer记结束时间，禁用time.now().sub()高并发统计。
Go HTTP中间件里怎么正确记录响应时间
直接用 time.Since(start) 不行——它测的是整个 handler 执行耗时，但 Go 的 http.ResponseWriter 是异步写回的，next.ServeHTTP() 返回时，响应可能还没真正发出去。真实响应时间得从底层连接关闭或写入完成那一刻才算完。
正确做法是包装 ResponseWriter，重写 WriteHeader() 和 Write()，并在最后一次 Write() 或 WriteHeader() 后记录时间；更稳妥的是结合 http.Hijacker 或使用 net/http/httputil.ReverseProxy 风格的代理式包装，但生产环境推荐用已验证的库，比如 go-chi/chi/middleware 里的 Logger 或 RealIP + 自定义耗时字段。
- 别在
defer里记结束时间：中间件链中若有 panic 恢复逻辑（如Recovery），defer可能晚于实际响应发出 - 避免用
time.Now().Sub()做高并发下的耗时统计：纳秒级精度没问题，但频繁调用time.Now()在百万 QPS 下有可观开销；可改用runtime.nanotime()（需自行转为time.Duration） - 结构化日志必须包含
status、method、path、duration_ms（单位统一为毫秒，整型）、user_agent和remote_ip（注意 X-Forwarded-For 处理）
用 GoAccess 分析 Nginx 日志里的响应时间要配对哪几个字段
GoAccess 要解析出有意义的响应时间分布，Nginx 日志里至少得暴露两个时间字段：$request_time 和 $upstream_response_time，且 GoAccess 的 --log-format 必须严格对齐位置。
典型 Nginx log_format 应含：'$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_time $upstream_response_time'。其中：
-
$request_time：Nginx 接收请求到返回响应的总耗时（含 upstream 等待 + Nginx 自身处理），对应 GoAccess 的%T -
$upstream_response_time：后端 Go 服务实际处理时间（不含 Nginx 解析 header、gzip 等），对应 GoAccess 的%^占位符后紧跟的字段，需在goaccess.conf中显式声明为response-time字段 - 若只写
$request_time，GoAccess 会误把网络传输、SSL 握手、Nginx 缓冲等全算进“接口耗时”，导致定位偏差
pprof CPU profile 抓不到热点，但接口就是慢，下一步查什么
pprof cpu.pprof 显示不出明显瓶颈，常见于两种情况：一是耗时分散在大量小函数调用中（如 JSON 序列化、map 查找、interface{} 类型断言），二是阻塞不在 CPU，而在 I/O 或锁上。
立刻切到其他 profile：
- 跑
go tool pprof http://localhost:6060/debug/pprof/block：看sync.runtime_SemacquireMutex或net/http.(*conn).read是否长期排在顶部——说明卡在锁竞争或上游未响应 - 抓
go tool trace：打开浏览器看 Goroutine analysis → “Long GC pauses” 或 “Scheduler latency”，确认是否 STW 过长或 P 数不足导致 G 队列堆积 - 检查
net/http/pprof的/debug/pprof/goroutine?debug=2：如果 goroutine 数量稳定在几百但接口延迟飙升，大概率是下游依赖（DB、Redis、gRPC）连接池耗尽或超时设置过长
为什么本地测很快，上线后 Go 接口响应时间翻倍
不是代码问题，而是环境差异放大了某些被忽略的路径开销。重点排查三类配置漂移：
- Nginx 层：线上开了
gzip on且压缩级别高（如gzip_comp_level 6），而 Go 服务返回的是大 JSON，CPU 全耗在压缩上；关掉 gzip 或降级到 1–2 级再测 - HTTP 客户端复用：本地直连 Go 服务，线上走 Nginx，但 Nginx 的
keepalive和 Go 的http.Transport.MaxIdleConnsPerHost不匹配，导致频繁建连；查 Nginx error log 里有没有upstream prematurely closed connection - 系统级限制：线上容器内存 limit 设得太低（如 512Mi），触发 cgroup 内存回收压力，runtime 会主动降低 GC 频率但增加单次 STW，表现为 pprof 里
runtime.mallocgc时间不长，但 trace 里 “GC pause” 波动剧烈
最常被跳过的点：Nginx 的 client_max_body_size 和 Go 的 http.MaxBytesReader 不一致，大请求体在 Nginx 缓冲区堆积，$request_time 拉长，但 Go 服务根本没收到完整 body。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
