K8s集群内流量录制应优先在HTTP handler入口（如中间件）捕获原始请求路径，而非依赖net/http默认RoundTripper，因其仅看到解析后的IP+端口，无法还原Service Mesh或Ingress的路由意图。
为什么 net/http 默认 RoundTripper 无法捕获集群内服务的真实请求路径
在 K8s 集群内做流量录制时，直接用 http.DefaultClient 或自定义 http.Client 发起请求，经常发现录到的 req.URL.Path 是空的、被截断的，或者和实际访问的服务名对不上。这是因为 K8s Service 的 DNS 解析（如 my-svc.default.svc.cluster.local）在 HTTP 层是透明的，RoundTripper 看到的是解析后的 IP + 端口，而原始 Host 和 Path 可能已被上游（比如 Istio sidecar、kube-proxy 的 iptables 规则）改写或丢弃。
真正要录“业务视角”的流量，得在应用层拦截未被重写前的请求上下文 —— 最可靠的位置是 HTTP handler 入口，而不是 outbound client 出口。
- 别试图在
http.Transport层靠RoundTrip钩子还原原始路径；它天然看不到 Ingress 或 Service Mesh 的路由意图 - 如果服务用了
istio-proxy，真实请求头里会有x-envoy-original-path或x-forwarded-path，但这些字段非标准、不可依赖 - 优先在
http.ServeMux或gin.Engine/echo.Echo的中间件里做录制，此时req.URL.Path和req.Host还是用户发起时的样子
如何用 http.Handler 包装器安全地录制请求而不破坏响应流
核心是不阻塞、不缓冲、不修改原始 http.ResponseWriter 行为，同时拿到完整请求体和响应体。Go 的 ResponseWriter 接口不暴露底层 buffer，所以必须用 wrapper 实现。
常见错误是直接读 req.Body 后没重置，导致下游 handler 读不到内容；或者把响应体全读进内存再写回，扛不住大文件或流式响应。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 对
req.Body：用io.TeeReader(req.Body, &buffer)边读边存，读完后用bytes.NewReader(buffer.Bytes())替换原Body - 对
http.ResponseWriter：实现自定义 wrapper，覆盖Write()、WriteHeader()、Header()方法，在Write()时追加到本地 buffer，但不要提前调用WriteHeader() - 务必在
defer里触发录制逻辑，确保即使 panic 也能落盘；但别在 defer 里做阻塞操作（比如同步写磁盘），应发到带缓冲的 channel 交给后台 goroutine 处理 - 示例关键片段：
type RecordingResponseWriter struct { http.ResponseWriter body *bytes.Buffer } func (w *RecordingResponseWriter) Write(p []byte) (int, error) { w.body.Write(p) return w.ResponseWriter.Write(p) }
k8s.io/client-go 不适合直接用于录制集群内服务调用
有人想用 client-go 的 RESTClient 拦截所有 API 调用，但这只管 K8s API Server 的请求（如 /api/v1/pods），和你的业务服务（如 http://user-service:8080/v1/users）完全无关。混淆这两者会导致录制目标彻底跑偏。
更隐蔽的问题是：如果你的服务本身用 client-go 调 K8s API，这部分流量确实可录，但它和业务链路是正交的，混在一起会污染分析结果。
- 区分清楚：业务服务间调用走的是普通 HTTP/TCP，用
net/http；K8s 控制面交互走的是client-go，用的是rest.Config+RESTClient - 若真要录 client-go 流量，得替换其
Transport字段，但注意它默认启用了 gzip、retry、timeout 等策略，钩子函数里需小心处理状态同步 - 绝大多数场景下，你该关注的只是自己服务的 inbound HTTP 请求，不是 client-go outbound 请求
录制数据落地时最容易被忽略的三个细节
流量数据最终要存下来供回放或分析，但很多实现卡在“能录”和“能用”之间，问题往往出在元数据缺失、格式松散或时间错乱上。
- 必须记录
req.RemoteAddr（哪怕只是"127.0.0.1"），否则无法区分同一路径下的不同调用来源；K8s Pod IP 变化快，建议额外加pod-name和namespace标签（从/proc/self/cgroup或环境变量取） - 响应体不要无条件全录：设置阈值（如
Content-Length 或 <code>Content-Type匹配application/json|text/.*），二进制或大文件只记摘要（sha256）和大小 - 时间戳必须用
time.Now().UTC()，别用req.Header.Get("X-Request-Start")等不可信头；K8s 节点时钟可能漂移，但至少保证同节点内顺序一致
流量录制不是越全越好，而是越准越好。一个漏掉 Host 头或写错 Content-Type 的录制条目，回放时大概率 415 或 404 —— 这种细节，调试时最花时间。
