rest.Interceptor 不能修改请求体，因 req.Body 已关闭；应优先用 header（如 X-Audit-User）或 query 参数传递审计信息；必须改 body 时需重建 io.NopCloser 并更新 ContentLength；Header 注入应通过 rest.WrapTransport 实现以确保重试不丢失；监听资源创建应使用 Watch + Get 全量对象校验终态，而非仅 Added 事件；审计日志应在 RoundTrip 出口、响应成功时记录终态信息。
client-go 的 rest.Interceptor 不能改请求体，别碰 Body
想在创建 Pod/Service 前注入字段（比如加 auditID 到 JSON body），直接在 rest.Interceptor.RoundTrip 里读取并重写 req.Body 会触发 http: read on closed body 错误。因为 client-go 在调用拦截器前已把 body 读完并序列化，此时 req.Body 是个已关闭的 io.ReadCloser。
真正能安全操作 body 的位置只有两个：rest.ClientContent（用于控制序列化前的数据）或自定义 http.RoundTripper（比如包装 rest.Transport）。但绝大多数审计、日志、轻量标记场景，根本不需要动 body —— 改 header 或 query 更稳妥。
- 审计字段优先走 header：
X-Audit-User、X-Request-ID，服务端可直接提取 - GET 类请求（如
List）可用 query 参数传递上下文，比如?audit_source=ci-pipeline - 必须改 body（例如 PATCH 请求补 metadata）？得用
bytes.Buffer+io.NopCloser重建req.Body，同时手动更新req.ContentLength；否则 kube-apiserver 可能因长度不匹配拒绝请求
用 rest.WrapTransport 注入 header 并确保重试不丢
Kubernetes 客户端默认重试逻辑（rest.DefaultBackoff）会在每次重试时新建 *http.Request，你在拦截器里用 req.Header.Set() 设置的 header 不会自动继承——重试后 header 就丢了。
正确做法是在初始化 rest.Config 后、传给 rest.NewRESTClient 前，用 rest.WrapTransport 包装底层 transport，并在它的 RoundTrip 中统一补 header：
立即学习“go语言免费学习笔记（深入）”；
config.WrapTransport = func(rt http.RoundTripper) http.RoundTripper {
return roundTripperFunc(func(req *http.Request) (*http.Response, error) {
req.Header.Set("X-Audit-User", "devops-bot")
req.Header.Set("X-Trace-ID", uuid.New().String())
return rt.RoundTrip(req)
})
}
- 这样所有请求（含重试）都会经过同一段逻辑，header 不会丢失
- 避免在拦截器里做
req.Header.Set后就以为“设过了”——那只是当前这一次 - 如果还要兼容
rest.AddUserAgent等已有 wrapper，注意调用顺序：你自己的 wrapper 应该包在最外层
Watch 创建事件时，别只监听 Added 类型
如果你的目标是“拦截资源创建”，实际往往不是拦截 HTTP 请求本身，而是监听集群中刚出现的资源——比如等一个 Pod 被调度成功再触发检查。这时候该监听 corev1.Pod 的 Watch 流，而不是试图 hook client-go 的 HTTP 层。
关键陷阱：只处理 watch.Added 事件会漏掉很多真实创建场景：
- 滚动更新时旧 Pod 被删、新 Pod 被加，
Added是新的，但你可能更关心它是否进入Running状态 - 某些控制器（如 Job）先建 Pod 再改其
OwnerReferences，第一次Added时字段还不全 - Watch 连接断开重连后，
Added是历史快照，不是“刚刚创建”
建议逻辑：收到 watch.Added 或 watch.Modified 后，立刻 Get 一次完整对象，检查 pod.Status.Phase == corev1.PodRunning 且 pod.Status.Conditions 中有 Ready=True，才算真正“可拦截的创建完成”。
审计日志要打在 RoundTrip 出口，且只打终态响应
在 rest.Interceptor.RoundTrip 入口打日志，会为每次重试都记一条，无法区分“一次用户请求”和“多次 HTTP 尝试”；在出口打，又容易因 context cancel 或 panic 漏记。
推荐策略：只在 RoundTrip 返回时，满足 err == nil && resp.StatusCode < 400 才记录终态审计日志，内容包含：
-
req.Method + req.URL.Path（如POST /api/v1/namespaces/default/pods） - 重试次数（可通过
req.Context().Value()透传计数器） - 总耗时（从第一次 RoundTrip 开始到终态响应）
-
resp.StatusCode和resp.Header.Get("X-Rate-Limit-Remaining")（便于后续限流分析）
别在日志里读 resp.Body —— 它是单次读取流，读完不 io.Copy(ioutil.Discard, resp.Body) 再 resp.Body.Close()，后续 client-go 解码会失败。轻量标识用 header 或 path 就够了。
