Go微服务中用http.RoundTripper实现请求镜像需确保不阻塞主链路、复用且不消耗原始Body；应使用io.TeeReader分流、独立短超时Client、禁用重定向，并通过ReverseProxy做网关级镜像，同时处理Header透传、TraceID派生、动态开关、白名单校验、QPS限流与日志脱敏。
Go 微服务中用 http.RoundTripper 实现请求镜像
镜像流量不是复制整个 HTTP 连接，而是把原始请求的副本发给另一个服务，主链路不受影响。关键在不阻塞、不修改原请求，且能复用原始请求体（Body 只能读一次）。
常见错误是直接 req.Body.Read() 后没重置，导致下游服务收不到 body；或者用 bytes.Buffer 全量缓存大文件请求，OOM 风险高。
- 必须用
io.TeeReader或io.MultiReader+bytes.NewBuffer分流，而不是先读再重写req.Body - 镜像请求应设独立
http.Client，超时比主链路更短（比如 200ms），避免拖慢主流程 - 务必禁用镜像请求的重定向（
CheckRedirect: func(req *http.Request, via []*http.Request) error { return http.ErrUseLastResponse }），防止旁路意外触发重放攻击或循环调用 - 示例片段：
mirrorBody, _ := io.ReadAll(req.Body) req.Body = io.NopCloser(bytes.NewReader(mirrorBody)) // 恢复原 Body go func() { mirrorReq, _ := http.NewRequest(req.Method, mirrorURL, bytes.NewReader(mirrorBody)) mirrorReq.Header = req.Header.Clone() mirrorClient.Do(mirrorReq) }()用
net/http/httputil.ReverseProxy做透明镜像网关如果你在 API 网关层统一做镜像（比如所有
/v1/路径的 POST 请求都镜像），ReverseProxy是更稳的选择——它天然处理 header、host、transfer-encoding，还能透传 streaming 请求。容易踩的坑是没覆盖
Upgrade和Connection头，导致 WebSocket 镜像失败；还有忽略Content-Length冲突，被后端拒绝。立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig下载使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须重写
Director函数，显式设置mirrorReq.URL.Host和mirrorReq.URL.Scheme，不能只改Path - 在
ModifyResponse中删掉镜像响应里的Set-Cookie、Location等敏感头，避免污染主链路 - 对大文件上传，启用
FlushInterval（如time.Millisecond * 10），否则镜像可能卡在缓冲区
镜像流量中的 Context 与 TraceID 传递问题
旁路请求如果带了和主请求一样的
X-Request-ID或traceparent，APM 系统会误以为是同一个调用链，导致指标混乱。但完全丢弃又不利于问题定位。正确做法是派生新 trace，并标注来源。OpenTelemetry Go SDK 提供
otel.Tracer.Start()的WithLinks()选项，可关联原始 span。- 不要直接拷贝
req.Context()到镜像请求，要用trace.WithSpanContext()显式构造新 span context - 在镜像请求 header 中加
X-Mirror-Source: true和X-Mirror-Original-ID: xxx，方便日志过滤 - 如果主服务用了
gin.Context或echo.Context，别从它们取Request.Context()后直接传给 goroutine——要提前提取必要字段（如 traceID 字符串），因为父 context 可能提前 cancel
生产环境必须关掉的镜像开关
镜像不是永远开启的功能。上线后若不控制，容易压垮测试环境、泄露敏感数据、或因配置错误把生产请求打到开发库。
最可靠的方式是运行时动态开关，而不是编译期 flag。靠环境变量或配置中心下发布尔值，每次镜像前检查。
- 开关判断必须放在最外层，比如
if !mirrorEnabled.Load() { return }，避免进函数才校验 - 镜像目标 URL 必须白名单校验（正则匹配
^https?://(staging|mirror)-.*\.example\.com$），禁止解析用户可控 host - 加 QPS 限流（比如每秒最多 50 个镜像请求），用
golang.org/x/time/rate.Limiter，别依赖上游限流——镜像本身就是绕过主限流的 - 记录镜像失败日志时，脱敏
req.URL.String()和req.Header.Get("Authorization")，但保留状态码和目标地址
真正难的不是怎么发出去，是怎么确保它只在该出现的时候出现，且出现时不留下痕迹、不干扰别人。开关、白名单、脱敏、限流——这四样少一个，旁路就从工具变成地雷。
- 必须重写
