go层自实现流量镜像需绕过req.body只能读一次的限制，通过io.readall一次性读取后分发，并用req.clone隔离修改，设置超时client静默处理失败，且必须受配置开关控制。
线上流量镜像不是“复制一份发出去”那么简单，Go 层自实现是可控性最强的方式，但必须绕过 req.Body 只能读一次这个坑。
为什么 httputil.NewSingleHostReverseProxy 做镜像要先读 body
HTTP 请求的 req.Body 是 io.ReadCloser，底层可能连着 socket 或 pipe。一旦被 io.ReadAll、io.Copy 或框架（如 Gin 的 c.ShouldBindJSON）消费一次，再次读就返回 EOF——主链路解析失败，镜像链路也拿不到原始数据。
- 必须用
io.ReadAll(req.Body)一次性读完原始字节，再用bytes.NewReader()分别喂给主 handler 和镜像 proxy - 不能直接传
req.Body给proxy.ServeHTTP，否则主流程收不到 body - 读完后记得调用
req.Body.Close()，避免连接泄漏（尤其在复用连接时）
如何安全克隆请求并设置镜像目标
直接修改原 *http.Request 会污染主链路：比如改了 req.URL.Host，后续中间件或日志就全乱了；Header 被加了 X-Mirror-Source，也可能影响鉴权逻辑。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
req.Clone(req.Context())创建全新请求对象，隔离修改 -
proxy := httputil.NewSingleHostReverseProxy(&url.URL{Scheme: "http", Host: "mirror-service:8080"})不会自动覆盖请求 Host，必须显式设mirrorReq.URL.Host = "mirror-service:8080" - Header 需手动复制：
mirrorReq.Header = make(http.Header)，再用req.Header.Clone()或逐项拷贝（注意跳过敏感头如Authorization）
镜像失败绝不能拖慢主响应
镜像只是旁路观察，超时、连接拒绝、5xx 响应都该静默吞掉，主请求耗时不能因此增加 1ms。
- 必须用带超时的
http.Client替换 proxy 默认 client：proxy.Transport = &http.Transport{RoundTrip: &http.Transport{}.RoundTrip, ...}更稳妥的是直接封装：proxy.Transport = &http.Transport{...}; proxy.Transport.(*http.Transport).DialContext = ... - 推荐超时值：
3 * time.Second，比主链路超时短，且留出重试余量 - 错误日志里至少记录
mirror_url、status_code、err.Error()，但不要 panic 或 return error 给上层
什么时候不该用 Go 自实现镜像
如果你只需要 header + method + path 的粗粒度镜像，且集群已跑 Istio，那直接配 VirtualService.mirror 更轻量——Go 层镜像真正的价值在于 body 完整性、条件过滤和可观测性。
- 需要镜像 gRPC 流式请求？Go 自实现需额外处理
grpc.ClientConn和 stream 复制，远比 HTTP 复杂，此时优先考虑 Envoy Filter 或 goreplay - 镜像目标是外部 SaaS（如 Sentry、Datadog）？它们通常不接受 raw HTTP 请求体，得在镜像服务里做协议转换，Go 自实现反而增加维护成本
- 要压测回放？goreplay 的
--input-file+--output-http支持倍速、循环、限流，比手写更稳
最易被忽略的一点：所有镜像逻辑必须包裹在 if config.MirrorEnable 开关下，本地开发和测试环境默认关闭，上线前才通过配置中心动态打开——否则 debug 时一不小心就往测试库发了真实订单。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
