go微服务网关中用http.handler实现请求耗时拦截，需在servehttp中用time.now()起始计时，包装responsewriter覆盖writeheader/write以捕获真实状态码与流式响应耗时，避免defer或超时handler内层嵌套导致统计偏差，并通过采样策略对接prometheus指标。
Go微服务网关中如何用http.Handler实现请求耗时拦截
直接在网关入口加一层包装即可，不需要框架或中间件库。核心是利用http.Handler的组合能力，把耗时统计逻辑塞进ServeHTTP方法里。
常见错误是把计时逻辑写在defer里但没处理panic导致耗时不准，或者漏掉对WriteHeader和Write的覆盖，导致实际响应时间被低估。
- 必须在
respWriter.WriteHeader和respWriter.Write里也埋点，否则无法捕获流式响应（如sse、chunked）的真实耗时 - 用
time.Now()而非time.Since()做起点，避免因GC暂停导致的微秒级漂移（对P99影响小，但P999敏感） - 记录时建议用纳秒级整数，避免浮点转换开销；打日志时再转成
ms格式
type DurationHandler struct {
next http.Handler
}
func (h *DurationHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
start := time.Now()
lw := &responseWriter{ResponseWriter: w}
h.next.ServeHTTP(lw, r)
dur := time.Since(start).Nanoseconds()
log.Printf("[DURATION] %s %s %d %dms", r.Method, r.URL.Path, lw.status, dur/1e6)
}
type responseWriter struct {
http.ResponseWriter
status int
}
func (rw *responseWriter) WriteHeader(code int) {
rw.status = code
rw.ResponseWriter.WriteHeader(code)
}
func (rw *responseWriter) Write(b []byte) (int, error) {
if rw.status == 0 {
rw.status = 200
}
return rw.ResponseWriter.Write(b)
}
为什么不能只依赖net/http的Server.Addr做耗时统计
因为Server.Addr监听层只管连接建立和TLS握手，不包含路由分发、后端转发、重试等网关特有环节。真实耗时必须从网关收到完整请求头开始算起。
典型场景：某次请求经过JWT校验→限流→负载均衡→上游超时重试→最终返回，整个链路耗时可能比Server.Serve统计的长2~3倍。
-
http.Server的Handler字段是唯一可靠入口点，所有请求必经此处 - 若使用
gorilla/mux或gin等路由库，拦截器必须放在它们的Handler外层，否则会漏掉404、405等未匹配路由的耗时 - 注意
http.TimeoutHandler会包裹原始Handler，你的耗时拦截器必须包在它外面，否则超时中断的请求会被记为0ms
如何让耗时数据支持Prometheus指标暴露
直接用prometheus.NewHistogramVec定义指标，但关键在于采样策略——全量打点会拖慢网关，尤其在QPS过万时。
错误做法是给每个请求都Observe()，正确做法是按路径+状态码维度采样，且默认关闭全量采集。
- 配置项
duration_sample_rate设为0.01（即1%），对高频路径（如/health）可设为0，对低频业务路径（如/v1/order/create）设为1.0 - 指标名用
gateway_request_duration_seconds，标签必须含path（截断到两级，如/v1/user/*）、status_code、method - 直方图
Buckets建议设为[]float64{0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5}，覆盖毫秒到秒级常见区间
Go网关拦截器里容易忽略的上下文泄漏问题
耗时拦截本身不带context，但如果你在拦截器里调用了下游服务或日志系统，而没显式传入r.Context()，就会导致span丢失、超时传递失效、甚至goroutine泄露。
最隐蔽的坑是：日志库（如zap）默认不继承request context，你看到的traceID可能是空或错乱的。
- 所有异步操作（如上报耗时到kafka）必须用
ctx, cancel := context.WithTimeout(r.Context(), 500*time.Millisecond)包裹，并在defer里调用cancel() - 不要在拦截器里启动
go func() { ... }()而不传context，这类goroutine大概率成为孤儿 - 如果用了OpenTelemetry，确保
otelhttp.NewHandler包装的是你最终的Handler，而不是中间某一层，否则span嵌套会错乱
耗时拦截看似简单，真正难的是在高并发下保持低开销、不丢数据、不破context链路——这些细节不压测根本看不出问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
