灰度发布在Go微服务中必须闭环实现请求标识、服务发现、下游透传、实例路由四环节。HTTP需在入口中间件提取X-App-Version并存入context，下游调用前显式设置header；服务注册须用metadata打标而非版本化服务名；gRPC需每跳显式处理metadata；路由决策必须前置至中间件，避免handler内判断导致初始化失效。
立即进入“夸克ai手把手教你，操作像呼吸一样简单！☜☜☜☜☜点击进入”；
灰度发布在 Go 微服务里不是“加个中间件就完事”，而是请求标识、服务发现、下游透传、实例路由四个环节必须闭环，缺一不可。硬编码版本判断或只在入口做 header 解析，上线后大概率出现灰度流量不生效、下游收不到标签、v2 实例被误调用等问题。
HTTP 请求头如何正确提取与透传
Go 的 http.Client 默认不会把上游请求头带到下游，这是最常踩的坑。现象是：API 网关收到 X-App-Version: v2，但调用下游服务时，对方 r.Header.Get("X-App-Version") 返回空字符串。
- 入口中间件必须从
r.Header.Get("X-App-Version")提取值，并存入context.Context（例如context.WithValue(r.Context(), "targetVersion", version)） - 下游 HTTP 调用前，必须显式设置：
req.Header.Set("X-App-Version", version)；不能依赖WithContext自动携带 - 若用
gin或echo，避免在 handler 内部才解析——应放在Use()中间件，早于所有业务逻辑执行 - Nginx 或 API 网关（如 Kong）需确认未过滤自定义 header，例如 Nginx 要配
proxy_pass_request_headers on;
服务注册时怎么打标签才真正可用
把服务注册成 user-service-v2 是反模式。注册中心应统一用服务名 user-service，靠元数据（metadata）区分版本，否则客户端无法做动态路由决策。
- Consul 注册时用
Meta字段，例如：map[string]string{"version": "v2", "stage": "canary", "weight": "5"} - Nacos 注册时填
metadataJSON，字段名保持小写一致（version不要写成Version），避免客户端解析失败 - go-micro / kratos / kitex 客户端必须启用带标签过滤的
Selector，不能直接用默认轮询；例如micro.Selector(Selector.WithFilter(func(s *registry.Service) bool { return s.Metadata["stage"] == "canary" })) - 不要依赖注册中心“自动过滤”——客户端应拉取全量实例后本地过滤，更可控且避免中心节点延迟导致灰度失效
gRPC 场景下 metadata 必须双向显式处理
gRPC 的 metadata.MD 是单向容器，server 收不到 client 发的 metadata，除非 client 主动注入；server 也无法自动把 metadata 透传给下一级，必须每跳都手动附加。
- client 发送前：用
metadata.Pairs("x-app-version", "v2")构造md，再通过metadata.NewOutgoingContext(ctx, md)注入 context - server 接收时：调用
metadata.FromIncomingContext(ctx)获取md，再用md.Get("x-app-version")判断是否灰度 - server 调用下游 gRPC 时：必须重新构造
md并注入新 context，不能复用上游的ctx——因为FromIncomingContext返回的是只读副本 - 拦截器（interceptor）不会自动透传 metadata，每个 RPC 方法调用都要自己处理，没捷径
为什么灰度策略不能只写在业务 handler 里
把灰度判断逻辑（比如查 Redis 规则、计算 UID 哈希）放在 handler 函数内部，会导致连接池、DB 初始化、缓存预热等操作已按默认版本完成，灰度实际没生效。
- 路由决策必须在中间件层完成，且早于任何 service 层初始化
- 目标实例地址或服务名（如
"user-service-canary"）应存入 context，并由统一的 HTTP client 或 gRPC client 从 context 读取，而非硬编码 - 规则匹配尽量轻量：用内存 map 预热 + LRU 缓存，避免每次请求都查 DB 或远程配置中心
- fasthttp 没原生 context，得用
ctx.UserValue("target_service")，注意类型断言和 nil 判断
灰度不是“让 v2 上线”，而是“确保 v1 的兜底链路完全不受影响”。最容易被忽略的是健康检查和超时控制——v2 实例挂了，流量不该卡住，而应秒级切回 v1；v2 响应慢，不能拖垮整条调用链。这些不在路由逻辑里，但在生产环境决定灰度成败。
