rest.Interceptor 不能直接改写请求体，因为其 RoundTrip 方法接收的 *http.Request 的 Body 已被读取且不可重放，修改会触发“http: read on closed body”错误；真正可修改 Body 的位置是 rest.ClientContent 或自定义 rest.Transport。
为什么 rest.Interceptor 不能直接改写请求体
因为 Kubernetes 客户端的 rest.Interceptor 接口只暴露了 RoundTrip 方法，它接收的是已序列化的 *http.Request，而此时 req.Body 已被读取过、不可重放。想在拦截器里修改 JSON 请求体（比如注入审计字段），会触发 http: read on closed body 错误。
- 真正能改请求体的地方是
rest.ClientContent或自定义rest.Transport的RoundTrip实现 - 审计字段建议放在 HTTP Header（如
X-Audit-User）或 URL Query（对 GET 安全），而非篡改 Body - 若必须改 Body（如 PATCH 请求加 patch metadata），得用
bytes.Buffer+io.NopCloser重建req.Body，但要注意影响Content-Length和 streaming 行为
如何用 RetryWithExponentialBackoff 避免重试时丢失自定义 header
Kubernetes 客户端默认重试逻辑（rest.DefaultBackoff）会在重试时重新构造 *http.Request，但不会保留你在拦截器中设置的 header——除非你显式把它们塞进 req.Header 并确保每次重试都复用同一份引用。
- 不要在拦截器里用
req.Header.Set("X-Custom", ...)后就以为万事大吉；重试时这个req是新对象 - 正确做法：在初始化
rest.Config时配置Burst和QPS，再传给rest.NewRESTClient前，用rest.AddUserAgent或自定义rest.WrapTransport注入 header 逻辑 - 更稳妥的是用
rest.RetryOnConnectionFailure+ 自定义rest.Backoff，并在RoundTrip中统一补 header
RoundTrip 拦截器里记录审计日志的时机陷阱
审计日志如果只在 RoundTrip 入口打，会漏掉重试成功后的最终响应；如果只在出口打，又可能因 panic 或 context cancel 导致日志缺失。Kubernetes 客户端的 retry 机制让“一次 API 调用”和“一次 HTTP 请求”不是一一对应的。
- 推荐在
RoundTrip出口处，仅当err == nil && resp.StatusCode < 400时记录终态审计日志（含重试次数、耗时、status code） - 避免在入口记录 request body，尤其对 large object（如
PodYAML），容易 OOM；可用req.URL.Path+req.Method+req.Header.Get("User-Agent")做轻量标识 - 注意
resp.Body是 io.ReadCloser，日志里读完必须io.Copy(ioutil.Discard, resp.Body)再resp.Body.Close()，否则后续解码会失败
Go 1.21+ 下 context.WithValue 透传审计上下文的隐患
有人习惯在调用链开头用 context.WithValue(ctx, auditKey, auditData)，指望拦截器里能拿到。但 Kubernetes 客户端的 rest.Client 不会自动把 context 里的值映射到 HTTP header；而且 WithContext 只影响本次请求的 req.Context()，不改变 req 本身。
立即学习“go语言免费学习笔记（深入）”；
- 真正起作用的是
rest.Config.Wrap返回的http.RoundTripper，它接收原始*http.Request，不带 context 信息 - 若需透传，要么在发起 clientset 方法前手动设 header（如
clientset.CoreV1().Pods("ns").Create(ctx, pod, metav1.CreateOptions{DryRun: []string{"All"}})），要么用rest.Config.WrapRequest（v0.28+）钩子 - 别依赖
ctx.Value做关键审计字段传递，它易被中间件覆盖或丢弃；header 或 query 参数更可靠
最麻烦的其实是重试 + 流式响应（watch / exec）混用场景，这时候拦截器要区分 request 类型、判断是否可重试、还要保证 header 不重复添加——这些细节没写进文档，只能靠读 client-go 的 rest/request.go 和 transport.go 源码确认行为边界。
