Go微服务流量镜像需确保主链路零干扰、body完整、条件可控；关键在于提前读取并复用req.Body、隔离镜像请求上下文、设置短超时与禁用重定向、配置化开关及敏感字段过滤，必要时转向Istio镜像。
Go 微服务里做流量镜像，不是为了“复制转发”，而是要保证主链路零干扰、body 完整、条件可控；测试环境同步的关键不在“搭得全”，而在“隔离干净、配置可切、依赖可 mock”。
为什么 httputil.NewSingleHostReverseProxy 镜像必须提前读 body
因为 req.Body 是 io.ReadCloser，底层可能是 socket 连接。一旦被 io.ReadAll、c.ShouldBindJSON 或 proxy.ServeHTTP 消费一次，再次读就返回 EOF——主 handler 解析失败（报 invalid character），镜像请求也拿不到原始数据。
- 必须用
io.ReadAll(req.Body)一次性读完原始字节，再分别喂给主流程和镜像流程 - 读完后立刻调用
req.Body.Close()，避免连接泄漏（尤其在复用连接时） - 主 handler 的
req.Body要恢复为io.NopCloser(bytes.NewReader(bodyBytes)) - 镜像请求必须用
req.Clone(req.Context())创建新实例，否则改Host或加X-Mirror-Source会污染主请求
镜像目标 URL 和超时怎么设才不拖慢主链路
镜像只是旁路观察，失败不能影响主响应耗时。常见错误是直接用默认 http.Client，没设超时，或用了长连接池卡住主线程。
-
mirrorReq.URL.Host必须显式设为目标地址（如"traffic-mirror:8080"），NewSingleHostReverseProxy不会自动覆盖 - 镜像 client 超时建议设为
200ms ~ 500ms，比主链路短，且留出重试余量 - 务必禁用重定向：
CheckRedirect: func(req *http.Request, via []*http.Request) error { return http.ErrUseLastResponse } - 错误日志至少记录
mirror_url、status_code、err.Error()，但绝不panic或向上抛错
测试环境里怎么让镜像开关可控又不污染主逻辑
线上镜像需开关、白名单、脱敏；测试环境更进一步：要能完全绕过镜像目标，甚至把镜像请求打到本地 httptest.Server 做断言验证。
立即学习“go语言免费学习笔记（深入）”；
- 用配置项控制开关，比如
MIRROR_ENABLE=true+MIRROR_URL=http://localhost:9001，启动时加载 - 测试时把
MIRROR_URL指向testServer.URL，用gock或httptest拦截并校验镜像请求的Body、Header、Method - 敏感字段过滤写在镜像前：检查
req.Header.Get("X-Auth-Type") == "internal"就跳过 - 避免在
init()或包级变量里初始化镜像 client，改用构造函数注入，测试时可传 mock
什么时候该放弃自实现、转用 Istio mirror
自实现镜像价值在于 body 完整性、条件过滤、可观测性；但如果你只关心 header + path + method，且集群已跑 Istio，那配 VirtualService.mirror 更轻量。
- Istio 镜像默认不透传完整
req.Body（尤其 chunked / streaming 请求），也不返回镜像响应结果 -
mirror字段填服务短名（如"traffic-mirror"），不是完整域名；必须显式写mirrorPercentage: value: 100，不写就是 0% - 镜像请求的
Host头保持原样，但X-Forwarded-For和X-Request-ID会被重写，trace ID 不透传 - 本地开发联调时 Istio 环境往往不存在，而 Go 层镜像开关可由配置控制，启动即生效——这点没法替代
真正容易被忽略的，是镜像请求里的 Context 和 TraceID 处理：旁路请求如果带和主请求一样的 X-Request-ID，APM 系统会误认为是同一调用链；但完全丢弃又不利于定位问题。得派生新 trace ID，并加 X-Mirror-Source 标识，才能既隔离指标又保留溯源能力。
