fiber中间件不能直接实现灰度路由，因其仅运行于单实例内、无法跨进程调度流量；它只应负责识别灰度标识（如x-gray-version）并透传上下文，路由决策须由网关、注册中心或客户端负载均衡器完成。
Fiber 框架本身不内置灰度发布能力，中间件只是执行路由前/后的逻辑载体，真正实现灰度发布必须靠“识别请求特征 + 决策路由目标 + 透传上下文”三步闭环。直接写个中间件拦截并改 ctx.Request().URI() 或硬编码跳转，会破坏 Fiber 的路由树结构、丢失状态、无法配合反向代理或服务发现。
为什么不能只靠中间件做灰度路由
Fiber 的中间件（fiber.Handler）运行在单实例内，它看不到其他服务实例，也无法修改下游目标地址（比如把请求从 user-service 改发到 user-service-v2）。常见错误是：在中间件里用 ctx.Redirect() 或手动发起新 HTTP 请求，这会导致链路断裂、Header 丢失、超时不可控、监控断层。
灰度发布本质是**跨进程的流量调度问题**，不是单机逻辑分支。Fiber 中间件只适合做「染色」和「透传」，不是「路由」。
- 中间件能可靠做的事：提取
X-Gray-Version、校验用户 ID 是否在白名单、往ctx.Locals存标签、注入X-Forwarded-For等 - 中间件不能可靠做的事：决定该调哪个后端实例、修改负载均衡器的目标列表、更新注册中心元数据
- 典型翻车点：在中间件里用
http.DefaultClient.Do()转发请求 → 无法复用连接池、不走熔断、不带 traceID、日志无法关联
正确的灰度链路分工（Fiber + 外部组件）
把灰度拆成三层，Fiber 只负责最上层的「识别与透传」：
-
网关层（推荐 Nginx / APISIX / Spring Cloud Gateway）：接收原始请求，按 Header/Cookie/Query 做权重路由，把
lb://user-service分流到user-service-v1或user-service-v2实例组 -
注册中心（Nacos / Consul / Eureka）：每个 Fiber 实例启动时注册元数据，如
metadata: {version: "v2", weight: 30, gray-tag: "internal"} - Fiber 应用层（你写的代码）：用中间件完成两件事 —— 提取灰度标识、透传给下游（Feign/RestTemplate/gRPC）
例如，在 Fiber 中间件里确保 X-Gray-Version 不被丢弃：
app.Use(func(c *fiber.Ctx) error {
// 从 header、cookie、query 中任一位置提取灰度标识
version := c.Get("X-Gray-Version")
if version == "" {
version = c.Cookies("gray_version")
}
if version == "" {
version = c.Query("gray_version")
}
// 存入 locals，供后续 handler 使用
c.Locals("gray_version", version)
// 透传给下游服务（如果本服务还要调其他服务）
c.Request().Header.Set("X-Gray-Version", version)
return c.Next()
})
Fiber 中间件如何配合 LoadBalancer 做灰度选择
如果你用的是 Go 生态的客户端负载均衡（如 kitex、rpcx 或自研 roundrobin），Fiber 中间件可以提前把灰度信息塞进 context，让下游调用时能读取：
- 在中间件中调用
c.Context().Value()或c.Locals()获取灰度标签 - 构造自定义
context.Context并注入 key-value，传给 RPC client - 下游服务的负载均衡器根据该 context 中的
gray_version过滤实例列表
关键点：Fiber 中间件不参与实例选择，只提供决策依据。选择动作必须由客户端 SDK（如 Kitex 的 Extension）或服务网格（如 Istio）完成。
示例伪代码（Kitex 场景）：
// Fiber 中间件
app.Use(func(c *fiber.Ctx) error {
ver := c.Get("X-Gray-Version")
// 注入到 kitex 的 ctx
kitexCtx := kitex.With baggage(context.Background(), "gray_version", ver)
c.Locals("kitex_ctx", kitexCtx)
return c.Next()
})
// 在 handler 里调用下游
func getUser(c *fiber.Ctx) error {
kitexCtx := c.Locals("kitex_ctx").(context.Context)
resp, _ := userClient.GetUser(kitexCtx, &request)
}
最容易被忽略的透传陷阱
灰度失败十次有八次是因为 Header 透传断在某个环节。Fiber 默认不会自动转发所有 Header，尤其注意以下三点：
-
X-Gray-Version必须显式调用c.Request().Header.Set()，否则下游收不到 - 如果用了反向代理（如 Nginx），确认它没过滤掉自定义 Header（检查
underscores_in_headers和proxy_pass_request_headers） - 若下游是 Java 服务，Spring Cloud Gateway 默认会 strip 掉带下划线的 Header（如
X_Gray_Version），务必用短横线命名
真正的灰度控制权不在 Fiber 代码里，而在网关配置、注册中心元数据、以及客户端 SDK 的负载策略中。Fiber 中间件只是那个默默把标签贴好、递出去的人 —— 贴歪了，后面全错。
