灰度发布在go微服务中依赖请求标识透传、路由决策前置和服务发现打标三者协同；http需手动透传x-gray-id头，grpc须用metadata显式传递，路由必须前置到网关或服务发现层。
灰度发布在 Go 微服务中不是靠某个库自动完成的，而是靠请求标识全程透传 + 路由决策提前执行 + 服务发现打标三者协同；漏掉任何一环，流量就会“脱染”或路由错乱。
HTTP 请求头必须显式透传，net/http 不会帮你带过去
现象是：A 服务收到 X-Gray-ID: v2，调 B 时 B 的 r.Header.Get("X-Gray-ID") 返回空字符串。这不是 bug，是 net/http 的设计——http.Client.Do() 不会自动把 incoming request headers 复制到 outgoing request。
- 每次发起下游 HTTP 请求前，必须手动补头：
req.Header.Set("X-Gray-ID", grayID)，且要在http.DefaultClient.Do(req)之前 - 若用了自定义
RoundTripper（比如加了重试、trace 或超时封装），要检查是否在Clone()*http.Request时丢掉了非标准 header - 别依赖
gin.Context.Request.Header上的修改——它只影响当前请求生命周期，不会自动带到下游 - 推荐封装一个
CopyGrayHeaders(upstream, downstream *http.Request)工具函数，只拷贝X-*类关键 header，并用http.CanonicalHeaderKey统一大小写
context.Value 不可靠，每层中间件都得重新从 Header 提取
常见错误是网关在入口写了 ctx = context.WithValue(ctx, grayKey, "v2")，然后下游 handler 直接 ctx.Value(grayKey) 取值——这极易失效。中间任意一层日志 wrapper、panic 恢复、或框架内部新建 context 都可能覆盖掉原始值。
- 所有 HTTP handler 必须在中间件里显式调用
r.Header.Get("X-Gray-ID")，再存入自己的 context - 在 Gin 中更可控的做法是用
c.Set("gray-id", val)+c.MustGet("gray-id").(string)，避免原生context的类型断言风险 - fasthttp 没标准 context，必须用
ctx.UserValue("gray-id")，且每次取值都要做类型断言：v, ok := ctx.UserValue("gray-id").(string)，否则 runtime panic - 不要信任上游传来的
context值；它可能是空、过期、或被其他中间件污染
gRPC 灰度透传必须用 metadata，context.WithValue 完全无效
grpc-go 的 context 传播和 wire 层是分离的。context.WithValue(ctx, key, val) 写进去的灰度字段，server 端根本收不到——metadata 不会自动从 context 同步到 wire 上。
- client 发起调用前，必须构造
metadata.MD：md := metadata.Pairs("x-gray-id", grayID)，再用grpc.Header(&md)或metadata.NewOutgoingContext(ctx, md) - server 端需在 interceptor 里用
metadata.FromIncomingContext(ctx)提取，不能依赖ctx.Value() - 若链路是 A→B→C，且每跳都要判断灰度策略，那么 B 在调 C 前也得手动提取 + 附加 metadata，不能指望拦截器默认转发
- 别指望 gRPC 拦截器自动透传自定义 metadata；必须显式读、显式写
灰度路由不能写在业务 handler 里，必须前置到服务发现或网关层
把灰度逻辑塞进 handler，会导致 DB 连接池、缓存 client、限流器等组件已经按默认配置初始化完毕，再切版本就晚了。
- 分流逻辑必须放在所有业务 handler 之前，最好在网关或负载均衡层统一处理
- 新旧版本服务注册到 Consul/Nacos 时，必须带 metadata 标签，例如：
map[string]string{"version": "v2.1", "stage": "canary"} - 客户端 SDK 或网关应基于这些标签过滤实例，而不是在业务代码里硬编码
if header == "v2" { callUserServiceV2() } - 权重分流（如 v1:90%, v2:10%）需在服务发现返回的实例列表上做加权随机，不能靠
rand.Intn()实时生成——它不保证同用户稳定落到同一版本
最易被忽略的点是：灰度标识从入口开始就必须存活于每一跳的 wire 上，而不是只活在某一层的内存变量里；只要有一层没手动透传 header 或 metadata，整条链路就断染了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
