灰度标识必须在网关层统一注入，不能由业务服务自行解析；网关提取x-gray-tag等并作为标准header转发，gin服务只信任该清洗后header，避免二次校验或取模操作。
灰度标识必须在网关层统一注入，不能由业务服务自行解析
Gin 本身不处理跨服务的上下文透传，如果每个微服务都自己从 X-Release-Stage 或 Cookie 里取灰度标记，会导致链路断裂、逻辑重复、判断不一致。真实生产中，所有灰度决策应始于网关（或最外层反向代理），并在请求进入第一个 Gin 服务时就完成解析与注入。
推荐做法是：在网关（如 Nginx + Lua、Spring Cloud Gateway 或自研 Gin 网关）中提取 X-Gray-Tag 或 X-User-Id，然后作为标准 header 转发；后端 Gin 服务只信任这个已清洗过的 header，不再二次校验来源。
- 避免在业务服务里写
c.GetHeader("X-User-Id") % 100 这类逻辑——它无法保证全链路一致性，且难以灰度比例收敛 - 网关转发时务必保留原始 header，例如用
proxy_set_header X-Gray-Tag $http_x_gray_tag;（Nginx）或显式设置c.Request.Header.Set("X-Gray-Tag", tag)（Gin 网关） - 若无独立网关，可在主 Gin 服务最外层加一个中间件，但需严格限定只运行一次，防止被子服务重复调用
路由分流必须结合服务注册中心的元数据过滤，不能仅靠随机数或轮询
只在 Gin handler 里用 rand.Float64() 决定调用 v2 实例，属于伪灰度：它无法控制下游实例是否真的带 <code>stage=canary 标签，也无法应对实例扩缩容或下线场景。真正的分流必须发生在服务发现环节。
以 etcd 为例，Gin 服务在发起 HTTP 调用前，应先查 etcd 的 /services/order/v2?metadata.stage=canary 获取可用节点列表，再从中选一个；若没匹配到，则 fallback 到 stage=stable 实例。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 不要在代码里硬编码
[]string{"http://order-v2-1:8080", "http://order-v2-2:8080"}—— 这绕过了服务发现，等于放弃灰度治理能力 - 客户端 SDK（如自研 http client）需支持按 metadata key/value 过滤实例，例如
client.Call(ctx, "order", map[string]string{"stage": "canary"}) - etcd/Nacos 中注册时，必须写入完整元数据：
{"version":"v2.1.0","stage":"canary","weight":"10"}，其中weight用于后续加权负载均衡
Gin 中间件提取灰度标识后，必须存入 context.Context 而非全局变量或 map
用 ctx := context.WithValue(c.Request.Context(), "gray_tag", tag) 是唯一安全方式。任何把灰度信息塞进 map[string]interface{}、全局 sync.Map 或结构体字段的做法，都会导致并发读写 panic 或上下文丢失。
尤其注意：Gin 的 c.Copy() 不复制 context，c.Request.Clone() 才保留 context 值；下游调用如用 http.NewRequestWithContext()，必须显式传入 c.Request.Context()，否则灰度标记断链。
- 禁止使用
globalStage = tag这类全局变量——它在高并发下必然错乱 - 日志打标、指标上报、熔断判断等所有依赖灰度状态的地方，都应通过
ctx.Value("gray_tag")获取，而不是重新解析 header - 若需透传至 gRPC 下游，须将灰度字段写入
metadata.MD，并在服务端用grpc.Peer或拦截器还原为 context 值
全链路灰度失效最常见的原因是 header 未透传或 context 未延续
一个典型断点：Gin 服务 A 收到 X-Gray-Tag: true，正确注入 context 并调用服务 B；但调用时用了 http.NewRequest("GET", url, nil)，没带 header 也没传 context，服务 B 就收不到标记，自动走 stable 分支——整条链路灰度失效。
修复关键点只有两个：header 显式透传 + context 显式延续。其他所有“自动透传”方案（如某些中间件声称的“透明染色”）在 Go 生态中并不存在可靠实现。
- 每次 HTTP 调用前，必须手动设置：
req.Header.Set("X-Gray-Tag", tag)，且 tag 来自ctx.Value("gray_tag")，不是重读 header - gRPC 调用必须用
grpc.Header或metadata.AppendToOutgoingContext()注入，服务端用metadata.FromIncomingContext()提取 - 异步任务（如 Kafka 消费）无法继承 HTTP context，需在发消息时把
gray_tag作为 payload 字段或 header 透传，消费端再重建 context
