Go HTTP 权重分流需自定义中间件实现，推荐 chi.Router 配合一致性哈希（如基于 X-Request-ID），避免硬编码和浮点运算，确保流量稳定可复现。
Go HTTP 路由怎么按权重分流到不同 handler
Go 标准库 http.ServeMux 不支持权重分流，必须自己实现或换路由库。直接写 if-else 判断请求头/参数做路由分发，短期能用，但权重配置硬编码、无法热更新、不支持平滑切流。
推荐用 gorilla/mux + 中间件，或更轻量的 chi.Router 配合自定义中间件。核心思路是：在请求进入业务 handler 前，根据权重决定调用哪个后端逻辑（比如 handlerA 或 handlerB），而不是靠路由路径区分。
- 权重值建议用整数（如 70/30），避免浮点精度问题和除零风险
- 分流逻辑必须放在所有业务 handler 外层，否则中间件链路可能被跳过
- 不要在 handler 内部用
rand.Intn()—— 没有 seed 控制时每次重启行为不可复现，也难调试
用 chi.Router 实现可配置的权重分流中间件
chi 的中间件天然支持嵌套和条件跳过，比手动拼 http.Handler 更清晰。关键不是“注册多个路由”，而是“一个路由入口，内部按权重代理”。
示例逻辑：对 /api/order 所有请求，70% 流向旧版 orderV1Handler，30% 流向新版 orderV2Handler：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func weightedHandler(v1 http.Handler, v2 http.Handler, weight int) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
// 使用请求 ID 或 header 做一致性哈希，避免单个用户来回跳
hash := fnv.New32a()
io.WriteString(hash, r.Header.Get("X-Request-ID"))
if int(hash.Sum32()%100) < weight {
v1.ServeHTTP(w, r)
} else {
v2.ServeHTTP(w, r)
}
})
}
r := chi.NewRouter()
r.Post("/api/order", weightedHandler(orderV1Handler, orderV2Handler, 70))
- 用
X-Request-ID做哈希能保证同一请求始终走同一路，避免事务中断或状态不一致 - 别用
time.Now().UnixNano()当随机源 —— 高并发下容易碰撞，且无迹可查 - weight 参数范围必须是 0–100，超出要 panic 或 log.warn，否则分流比例失控
灰度发布时怎么让特定用户固定走新版本
纯随机或哈希分流不够灵活。真实场景需要“登录用户 ID=12345 一定走 V2”，或“带 X-Env: staging header 的全走 V2”。这得在权重逻辑前加白名单判断。
顺序很重要：先检查白名单 → 再检查灰度比例 → 最后 fallback 到默认版本。否则权重会覆盖人工干预。
- 白名单优先级永远高于权重，哪怕权重是 0% 也要放行
- 从
r.URL.Query().Get("debug")读开关不如从 header 读，避免 URL 泄露灰度标识 - 白名单数据建议从外部加载（如 etcd / configmap），不要写死在代码里，否则每次改都要发版
上线后怎么验证分流是否符合预期
看日志只能确认“有没有走新 handler”，看不出实际比例。必须埋点统计：在每个分支 handler 开头记录指标，例如 Prometheus 的 http_requests_total{version="v2", path="/api/order"}。
临时验证可以用 curl 批量压测，但要注意：curl -H "X-Request-ID: test-$(date +%s%N)" http://localhost/api/order，确保每次请求 ID 不同，才能测出真实分布。
- 别依赖 access log 里的 IP 做统计 —— 反向代理后全是 127.0.0.1
- 如果用 Nginx 做前置分流，Go 服务里就不要再重复做权重，容易叠加导致比例失真
- 权重配置变更后，必须等所有长连接复用周期过去（比如 keep-alive 超时时间），才能看到真实生效效果
权重分流本身不难，难的是把一致性哈希、白名单、指标采集、配置热加载这几块串成一条可运维的链路。少一环，线上就容易出现“说好 10% 灰度，结果 80% 用户卡在新版本报错”的情况。
