流量镜像是在主链路异步复制请求发往镜像服务，Go中不能直接用http.Handler做复制，因http.Request.Body是单次读取的io.ReadCloser，读取后即耗尽，需提前缓存并重置Body以供双写。
什么是流量镜像，Go 里为什么不能直接用 http.Handler 做复制？
流量镜像（Traffic Mirroring）本质是把一份生产请求**异步、非阻塞地复制一份发往镜像服务**，主链路响应不受影响。Go 的 http.Request Body 是单次读取的 io.ReadCloser，一旦被 http.ServeMux 或你的 handler 调用 ParseForm/json.Decode 等方法读取，Body 就被消耗掉，无法再读给镜像端 —— 这是最常见的“镜像发出去却是空 body”的根源。
必须在请求进入业务逻辑前完成 Body 缓存和双写，且不能拖慢主流程。
用 httputil.NewSingleHostReverseProxy 搭配自定义 Director 实现零侵入镜像
这是最轻量、对现有 HTTP server 改动最小的方式：把原 handler 包装成一个“代理”，在转发前克隆请求，异步发镜像，再继续走原逻辑。关键点在于绕过 Body 读取冲突：
- 调用
req.Body = ioutil.NopCloser(bytes.NewReader(buf))重置 Body，供后续 handler 正常读取 - 镜像请求用独立的
http.Client（设置超时、禁用 KeepAlive 防连接堆积）异步发送，避免阻塞 -
Director函数里只改req.URL.Host和req.URL.Scheme，不碰 Body，确保原始请求结构完整
示例核心片段：
立即学习“go语言免费学习笔记（深入）”；
proxy := httputil.NewSingleHostReverseProxy(&url.URL{Scheme: "http", Host: "origin-service:8080"})
proxy.Director = func(req *http.Request) {
// 克隆请求用于镜像
mirrorReq := req.Clone(req.Context())
buf, _ := io.ReadAll(req.Body)
req.Body = io.NopCloser(bytes.NewReader(buf))
mirrorReq.Body = io.NopCloser(bytes.NewReader(buf))
<pre class="brush:php;toolbar:false;">// 异步发镜像（务必加 context.WithTimeout）
go func() {
client := &http.Client{Timeout: 5 * time.Second}
_, _ = client.Do(mirrorReq)
}()
// 原请求继续转发}
需要精确控制镜像内容？用中间件 + io.TeeReader 拦截 Body
当你要过滤特定 path、Header 或修改镜像 payload（比如脱敏），就得写显式中间件。此时不能依赖 httputil，而要用 io.TeeReader 在读取过程中同步写入 buffer：
- 用
bytes.NewBuffer(nil)创建缓冲区，在TeeReader的 writer 中写入 - 主 handler 从
TeeReader读 Body，镜像数据自动进 buffer - 注意：GET/HEAD 请求没有 Body，无需 tee；
Content-Length头要重算或删掉，否则镜像端可能拒绝 - 大文件上传场景慎用——buffer 全驻内存，应配合
io.MultiWriter直接流式写到磁盘或限速 channel
关键判断逻辑：
if req.Method != "GET" && req.Method != "HEAD" && req.ContentLength > 0 {
var buf bytes.Buffer
req.Body = io.NopCloser(io.TeeReader(req.Body, &buf))
// 后续可拿 buf.Bytes() 构造镜像请求
}镜像失败怎么办？别让异常穿透到主链路
镜像只是观测手段，任何错误（DNS 失败、连接超时、5xx 响应）都必须吞掉，绝不能 panic、return error 或修改原响应状态码。
- 异步 goroutine 内必须 recover，日志记录用
log.Printf("[mirror] failed: %v", err)，不要用log.Fatal - 避免用全局
http.DefaultClient，它共享 Transport，镜像失败可能拖垮主请求的连接池 - 高频镜像时加简单限流（如
time.AfterFunc延迟发送，或用带缓冲 channel 控制并发数），防止压垮镜像服务
真正容易被忽略的是 Header 透传：镜像请求默认不带 Authorization、X-Forwarded-For 等敏感头，需手动 copy，但也要检查是否允许透传 —— 比如测试环境镜像到公网服务时，漏掉 Authorization 复制会导致镜像端鉴权失败，而你主链路完全感知不到。
