AB测试的核心是请求路由决策点，需在入口处实时分流，满足可复现、可配置、可追溯要求，避免硬编码随机逻辑。
AB测试的核心不是框架，而是请求路由决策点
Go 微服务做 AB 测试，不依赖特定“AB测试框架”，关键是在入口处（如 API 网关、HTTP 中间件或 RPC 拦截器）对每个请求做实时分流决策。这个决策必须满足：可复现（同一用户/设备/会话始终走同一路）、可配置（灰度比例、规则可动态调整）、可追溯（打标日志便于分析）。硬编码 rand.Float64() 看似简单，但线上无法控制、不可审计、不支持用户级保底，实际不可用。
用 HTTP 中间件实现可配置的 AB 分流（基于 Header / Cookie / Query）
在 Gin 或 Chi 等常用 Web 框架中，用中间件拦截请求，提取标识（如 X-User-ID、device_id、ab_group 查询参数），再查规则或哈希计算分组。不要用全局随机数，改用一致性哈希或 MD5(user_id + salt) % 100 —— 这样同一用户每次请求都得到相同分组，且扩容时影响可控。
实操建议：
- 优先从
X-Ab-GroupHeader 读取显式分组（用于人工调试或运营强制指定） - 未指定时，用
md5(user_id + "2024_ab_salt")[:4]转为 uint32，再对总流量比例取模（如 100 → 得 0–99 整数） - 将最终分组写入
ctx.Value()并注入下游 HTTP Header（如X-Ab-Group: v2），确保链路透传 - 记录日志字段：
ab_group=v2, ab_rule=hash_user_id, ab_salt_ver=1，避免事后无法归因
gRPC 场景下如何透传和决策 AB 分组
gRPC 没有天然的 Cookie 或 Query，必须靠 Metadata。客户端调用前需注入 ab-group 键值；服务端拦截器（grpc.UnaryServerInterceptor）从中提取，并同样做哈希或规则匹配。注意：Metadata 是 map[string][]string，取值要用 md.Get("ab-group") 并取第一个元素，否则可能 panic。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
常见错误现象：
- 客户端没设置 Metadata，服务端
md.Get("ab-group")返回空 slice → 后续逻辑 panic 或默认走主干 - 服务端修改了 Metadata 但没通过
grpc.SetTrailer()或重新封装 context → 下游服务收不到分组信息 - 不同语言客户端对 Metadata key 大小写处理不一致（如 Java 默认转小写）→ 建议服务端兼容
ab-group和AB-GROUP
配置热更新与降级：别让 AB 规则卡死整个服务
AB 规则（比如 “v2 对 5% 的 iOS 用户开放”）必须支持运行时更新。不要把规则写死在代码里，也不要用本地 JSON 文件轮询（IO 阻塞、无版本、无回滚）。推荐接入轻量配置中心（如 Nacos、Consul KV 或自建 HTTP 接口），用 sync.Map 缓存当前规则，并监听变更事件触发 reload。
关键细节：
- reload 时用双检查锁（
sync.Once或 CAS）避免并发覆盖 - 规则加载失败必须保留旧规则，不能清空 → 否则所有流量 fallback 到 default 组，可能引发雪崩
- 加一个兜底开关：
ab_enabled: false，出问题时一键关闭分流逻辑，只走主干路径 - 每秒统计各分组请求数，暴露为 Prometheus
ab_request_total{group="v1"}指标，便于快速发现倾斜或中断
真正难的不是写分流代码，是让每一次分组决策可解释、可回放、可对齐业务目标。比如运营说“iOS 新用户走 v2”，那你的哈希盐值、用户 ID 来源、新用户判定逻辑，都得和他们对齐，否则 AB 数据根本没法分析。
