在ReverseProxy的Director中埋点需将start := time.Now()置于函数首行，并通过context.WithValue注入req.Context()，后续在ModifyResponse或RoundTrip中读取start.UnixNano()整数计时，避免time.Since()浮点开销；responseWriter必须覆盖Write和WriteHeader以准确捕获流式响应终了耗时。
怎么用 time.Now() 在 ReverseProxy 的 Director 里埋点
不能只在 ServeHTTP 入口记一次开始时间，因为真正耗时大头常在转发后端、等待响应、读取 body 这几步。必须把计时起点前移到 Director 函数执行时——这时请求刚解析完，路由已匹配，但还没发出去。
常见错误是把 start := time.Now() 放在 proxy.ServeHTTP 外层，结果漏掉了 Director 里做服务发现、负载均衡选实例、重写 URL 等逻辑的开销。
-
Director函数里第一行就写start := time.Now() - 把
start通过context.WithValue注入到req.Context()，后续在ModifyResponse或自定义RoundTrip中读取 - 别用
time.Since(start)计算，直接存start.UnixNano()整数，避免浮点转换和 GC 压力
为什么 responseWriter 包装必须覆盖 Write 和 WriteHeader
标准 ReverseProxy 的 ModifyResponse 只在响应头收齐后触发，对流式响应（SSE、chunked）完全失效。真实耗时要等到最后一个 Write 返回才算结束，否则 P99 会被严重低估。
不覆盖 Write 的后果：日志里看到“200 OK 12ms”，实际用户等了 800ms 才收到完整数据。
立即学习“go语言免费学习笔记（深入）”；
当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。
- 必须实现自定义
responseWriter类型，嵌入原http.ResponseWriter -
WriteHeader里记录状态码并标记“头已发出” -
Write里检查是否首次写，是则补设默认状态码（如 200），再更新耗时统计 - 所有耗时计算统一用纳秒整数，打日志时再除以
1e6转 ms
httprouter 或 chi 路由层本身的耗时怎么单独剥离
网关总耗时 = 路由匹配 + 中间件执行 + 反向代理转发。若想定位是不是路由慢，得把路由匹配从整个链路中摘出来单独测。
net/http 的 ServeMux 是线性遍历，100 条规则平均要比 50 次；而 httprouter 用 Radix Tree，匹配复杂度只跟路径长度有关，但你得确认它真被用了——别让中间件或 panic 恢复逻辑干扰测量。
- 在
httprouter的Lookup方法调用前后加纳秒计时（不是Handle回调里） - 用
chi时，确保没在Route闭包里做耗时操作（比如每次请求都查 etcd） - 禁用所有中间件，只跑空路由 handler，测出基线值；再逐个打开 auth、log、rate-limit，看增量
- 压测时固定路径（如
/api/users/123），避免因路径参数解析引入额外开销
采样策略不当会让耗时指标完全失真
全量打日志或上报 Prometheus，QPS 上万时会直接拖垮网关自身。但采样太粗（比如每 1000 请求采 1 个），又看不出 P999 尾部毛刺。
更麻烦的是：只按请求频率采样，会漏掉慢请求本身——因为慢请求单位时间内的请求数少，被采中的概率反而更低。
- 用分层采样：100% 记录 5xx 错误、>2s 的请求；其余按固定比例（如 1%）随机采
- 别依赖
rand.Float64()做采样，用请求 ID 的哈希低字节判断，保证同一请求在重试时采样行为一致 - 在
ModifyResponse里根据耗时决定是否上报指标，而不是在入口统一采样 - 注意：
time.Now()在高并发下有微小漂移，对 P99 影响不大，但 P999 场景建议用runtime.nanotime()
resp.Body、甚至 log.Printf 里的字符串拼接。测耗时不是为了凑数字，而是逼你把每个隐式依赖都显式拎出来看一眼。 
