go微服务流量染色的核心是全程透传且不丢失x-gray-id：http需每层中间件显式提取并注入context，下游请求手动设置header；grpc须用metadata显式透传；fasthttp用uservalue+类型断言；禁止依赖上游context值。
Go 微服务流量染色的核心不是加个 header 就完事，而是确保这个标识从入口到最深下游每个 HTTP/gRPC 调用都不丢、不被覆盖、不被忽略。
HTTP 中间件里必须从 r.Header.Get("X-Gray-ID") 重新提取
常见错误是只在网关写一次 context.WithValue(ctx, grayKey, "v2")，然后 downstream handler 直接从 context 取——这完全不可靠。因为中间任何一层自定义中间件、日志 wrapper 或 panic 恢复逻辑都可能新建 context，把上游传的 key 覆盖掉。
- 所有 HTTP handler 必须在中间件里显式调用
r.Header.Get("X-Gray-ID")，并存入自己的 context（比如ctx = context.WithValue(ctx, grayKey, val)） - 不要信任上游传来的 context 值；它可能是空、过期、或被其他中间件污染
- 如果用了
gin.Context，建议用c.Set("gray-id", val)配合c.MustGet()，比原生 context 更可控
下游 HTTP 请求必须手动 set X-Gray-ID 头
Go 的 http.Client 不会自动把 incoming request headers 复制到 outgoing request。这是 net/http 的设计决定，不是 bug，但极易踩坑。
- 调用下游前，必须显式执行：
req.Header.Set("X-Gray-ID", grayID) - 这个操作要在
http.DefaultClient.Do(req)之前，且不能晚于req = req.WithContext(...) - 如果用了自定义
RoundTripper（比如加了重试或 trace），要检查是否在 clone*http.Request时漏掉了自定义 header —— 很多封装库会丢掉非标准头
gRPC 场景下必须用 metadata.MD 显式透传
gRPC 的 context 传播机制和 HTTP 完全不同。context.WithValue 里的灰度字段不会自动变成 wire 上的 metadata，server 端也收不到。
- client 发起调用前，必须构造 metadata：
md := metadata.Pairs("x-gray-id", grayID) - 再用
grpc.Dial(..., grpc.WithUnaryInterceptor(...))或直接grpc.Header(&md)注入 - server 端需在 interceptor 里用
metadata.FromIncomingContext(ctx)提取，不能依赖ctx.Value() - 别指望 gRPC 拦截器默认转发自定义 metadata；必须显式读、显式写
fasthttp 和无 context 场景要用 ctx.UserValue() + 类型断言
fasthttp 的 RequestCtx 没有标准 context 支持，ctx.Value() 是空接口，容易 panic。
- 存值：使用
ctx.UserValue("gray-id")，它返回interface{} - 取值：必须做类型断言，比如
v, ok := ctx.UserValue("gray-id").(string)，否则 runtime panic - 避免在中间件里查 Redis 或 DB 判断灰度规则；应预热到内存 map 或用 LRU cache，否则每次请求都阻塞
真正难的不是加一个 header，而是让整个调用链上每个环节都“记得”自己该传什么、该信什么、该拒绝什么。一旦某个中间件忘了 set header，或者某个 RPC client 没走 interceptor，染色就断了——而这种断裂往往只在灰度发布失败后才暴露出来。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
