echo框架不支持灰度分流，必须由网关或服务网格处理；echo仅负责灰度标识透传与轻量识别，硬编码if判断会导致业务耦合、规则僵化、服务发现失效，且header需手动拷贝以确保下游可获取。

Echo 框架本身不支持灰度发布分流，所有路由级灰度必须交由网关或服务网格层处理；Echo 只能做透传和轻量标识识别，硬编码版本判断会破坏可维护性与动态调整能力。

为什么不能在 Echo 路由里写 if header == "v2" { r.GET("/api/user", v2Handler) }

这种写法看似直接，实则埋下三个隐患：一是业务逻辑耦合路由决策，后续改策略要发版；二是无法按权重、用户 ID 哈希等复杂规则分流；三是绕过服务发现标签体系，注册中心打的 version=v2 或 canary=true 元数据完全失效。真正该由 Echo 做的，只是把请求上下文里的灰度标识安全透传下去。

HTTP Header 透传必须手动拷贝，http.Transport 不会自动带 X-* 头

常见错误是上游加了 X-Gray-Version: v2，下游用 c.Request().Header.Get("X-Gray-Version") 却返回空。原因在于 Go 的标准 HTTP 客户端默认不转发非标准头，Echo 中间件也不会帮你补全。

Skill Weave Chains — 技能链路由引擎

开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。

下载

• 在调用下游服务前，显式拷贝关键 Header：

  for k, vs := range c.Request().Header {
      if strings.HasPrefix(strings.ToLower(k), "x-gray-") || k == "X-Canary" {
          for _, v := range vs {
              req.Header.Add(k, v)
          }
      }
  }

• 避免用 req.Header.Set("X-Gray-Version", "v2") 后直接 client.Do(req)——中间代理（如 Kong、APISIX）可能静默 strip 掉 X- 类头，需确认网关配置了 enable-access-log 或显式放行
• 若封装自定义 RoundTripper，注意 http.CanonicalHeaderKey 会把 x-gray-version 转成 X-Gray-Version，下游匹配时大小写要一致

gRPC + Echo 混合场景下，grpc-gateway 必须启用 runtime.WithMetadata

当 Echo 作为 gRPC Gateway 暴露 HTTP 接口，并需要把 X-Gray-Version 映射为 gRPC Metadata 传递给后端 gRPC 服务时，不配置会导致元数据丢失。

• 初始化 gateway handler 时必须加：

  gatewayMux := runtime.NewServeMux(
      runtime.WithMetadata(func(ctx context.Context, req *http.Request) metadata.MD {
          if version := req.Header.Get("X-Gray-Version"); version != "" {
              return metadata.Pairs("x-gray-version", version)
          }
          return nil
      })
  )

• 否则 metadata.FromIncomingContext(ctx) 在 gRPC server 端拿不到 x-gray-version，链路中断
• 如果后端 gRPC 还要继续透传给下一级（如 A→B→C），B 必须用 metadata.AppendToOutgoingContext(ctx, md) 手动附加，不能依赖中间件自动传播

最易被忽略的是：灰度规则变更（比如从 5% 用户切到 10%）必须能在不重启服务的前提下生效。这意味着所有分流逻辑必须脱离 Echo 路由代码，落到 Istio VirtualService、Nacos 实例标签或 Kong 插件配置里——Echo 只保留最薄一层透传胶水逻辑。