Go 本身不提供灰度发布能力，需中间件提取灰度标识（如X-Gray-Id）、VersionRouter封装可热更策略路由，并结合服务发现按标签路由至新版本实例，同时保障可观测性闭环。
Go 本身不提供灰度发布能力，它只负责把请求接住、处理、返回——灰度的关键动作是「让一部分流量命中新版本」，这件事必须靠中间件识别标识 + 策略函数判断 + 路由分发协同完成，缺一不可。
用 GrayIDMiddleware 提取并透传灰度标识
灰度的前提是能识别谁该走新版本。别在每个 handler 里重复写 r.Header.Get("X-Gray-Id")，统一用中间件提取、注入 context：
- 优先从 Header（如
X-Gray-Id）读，再 fallback 到 Cookie 或 URL 参数 - 注入时用自定义 key（如
"gray_id"），避免和标准 context key 冲突 - 值不要直接传用户手机号、邮箱等敏感字段；建议用哈希后字符串或预分配的分组标签（如
"group-b"） - 若用 Gin，后续用
c.GetString("gray_id")拿；原生 http 则需显式调用r.Context().Value("gray_id")
用 VersionRouter 封装策略路由，而非硬编码 if-else
把「是否走灰度」的判断逻辑从业务 handler 中剥离出来，否则上线新策略就得改代码、重新部署：
- 定义结构体
VersionRouter，包含DefaultHandler、GrayHandler和Strategy函数 -
Strategy必须是可替换的：白名单查 Redis、用户 ID 取模、甚至对接配置中心的实时规则引擎 - 禁止在 handler 里写
if grayID == "123" { callV2() }—— 这类逻辑一旦变多，维护成本爆炸 - 示例中
isInWhitelist(grayID)应支持热加载，比如监听 etcd 变更后自动刷新内存 map
结合服务发现做实例级灰度，避免只靠 header 分流
纯靠中间件判断只是“请求染色”，真正落地灰度还要让请求打到带 gray=true 标签的新版本实例上：
立即学习“go语言免费学习笔记（深入）”；
- 注册服务时带上元数据：Consul 的
Tags: []string{"gray"}或 Nacos 的metadata字段 - 网关或客户端 SDK 查询服务列表时，按标签过滤（如只取
Tags含"gray"的节点） - 权重分流要用加权随机或一致性哈希实现，别用简单轮询——例如
v1权重 90、v2权重 10，就应确保约 10% 请求落到 v2 实例 - 注意缓存一致性：服务下线后，实例列表没及时更新会导致灰度流量误打到已终止的 pod 上
最容易被忽略的不是怎么写路由逻辑，而是灰度期间的可观测性闭环：日志没打标、指标没按 stage="canary" 分维、告警没单独阈值——等于蒙眼开车。上线前先确认 trace、log、metrics 三者都能按灰度标识对齐，否则出问题根本没法快速定位。
