灰度路由必须依赖HTTP Header或gRPC Metadata，Go微服务需在网关或入口解析X-Service-Version等标识，结合带版本标签的服务注册与按tag过滤的服务发现，并通过gRPC UnaryInterceptor透传metadata，精确路由与权重分流须分层实现。
灰度路由必须依赖 HTTP Header 或 gRPC Metadata
Go 微服务做灰度发布，核心不是“怎么升级”，而是“怎么把请求精准打到指定版本”。Golang 本身不内置灰度逻辑，必须在网关层或服务入口处解析 Header（如 X-Service-Version: v2）或 gRPC 的 metadata.MD，再据此选择后端实例。硬编码在 handler 里判断 req.Header.Get("X-Service-Version") 是最直接的方式，但容易和业务逻辑耦合；更稳妥的是用中间件统一提取并注入上下文。
服务注册时必须携带版本标签（tag），且 Consul / Nacos / ETCD 要支持按 tag 过滤
如果你用 consul，注册服务时得显式传入 Tags: []string{"version=v1.2.0", "env=gray"}；nacos 则需设置 metadata 字段，例如 {"version": "v1.2.0", "weight": "80"}。关键点在于：服务发现客户端（如 go-micro/registry/consul 或 hashicorp/consul/api）必须在 ListServices 或 Health.Service 调用中支持按 tag/metadata 过滤。否则即使注册了版本信息，上游也无法筛选。
gRPC 客户端透传 metadata 需手动注入，且 server 端必须用 UnaryInterceptor 拦截
HTTP 场景下 header 自动透传，但 gRPC 默认不透传 metadata。客户端发起调用前必须显式构造：
ctx = metadata.AppendToOutgoingContext(ctx, "x-service-version", "v2") resp, err := client.Call(ctx, req)
服务端则不能只在 handler 里用 metadata.FromIncomingContext——因为 gRPC 的 context 是 per-RPC 的，必须靠 grpc.UnaryInterceptor 统一拦截并写入 context.WithValue，否则下游服务拿不到原始灰度标识。漏掉 interceptor 是最常见的灰度失效原因。
立即学习“go语言免费学习笔记（深入）”；
权重路由 + 版本路由不能混用同一套配置逻辑
灰度常被误以为只是“按比例分流量”，但真实场景往往是“v2 版本只给 5% 流量”+“特定用户 ID 强制走 v2”。这两者策略不同：前者需要负载均衡器（如 Envoy、Nginx）做随机加权；后者必须靠路由规则匹配 header/metadata。Golang 服务自身不做权重分发，它只响应“该不该接这个请求”。所以你在 gorilla/mux 或 gin 里写的 if req.Header.Get("X-User-ID") == "12345" 是精确路由；而用 istio 或 linkerd 配置 weight: 5 才是概率分流。两者层级不同，强行在一个 Go handler 里用 rand.Float64() 做权重，会导致无法审计、不可回滚、不一致问题。
