Golang实现AB测试流量分配方案

本文深入解析了Golang中实现可靠AB测试流量分配的核心原则与工程实践，强调必须采用基于用户业务主键（如user_id）的稳定哈希（如fnv32a）而非随机数或IP进行分流，确保同一用户始终命中同一实验组；同时指出分流权重需动态配置、解耦策略与逻辑，并详述了中间件集成、反向代理透传、CDN缓存键设计、前后端哈希一致性、离线验证与线上监控等关键落地细节——真正决定AB测试成败的，不是算法有多复杂，而是全链路对用户标识的严谨传递与行为可预测性。

分流逻辑必须基于稳定哈希，不能用随机数

AB测试一旦上线，同一个用户反复访问必须命中同一组（A或B），否则数据不可信。用 math/rand 生成随机数会导致每次请求结果不同，用户在A/B间跳变，指标完全失真。

正确做法是提取用户标识（如 user_id、cookie_id 或客户端 IP 的哈希值），再对分组总数取模：

hash := fnv.New32a()
hash.Write([]byte(userID))
group := int(hash.Sum32() % 2) // 0 → A, 1 → B

• 优先用业务主键（如 user_id）而非 IP，避免内网用户集体归为同一组
• 哈希函数选 fnv 或 xxhash，比 md5 快且足够均匀；别用 sha256，纯属浪费 CPU
• 如果用 cookie 做标识，注意它可能被客户端篡改，需配合服务端签名校验

HTTP 中间件里做分流，但别在 handler 里硬编码

分流规则（比如 90% 流量进 A、10% 进 B）必须可动态配置，否则每次改比例都要发版。硬写死在中间件里等于把策略和逻辑耦合在一起，运维无法灰度调整。

建议把分流配置抽成结构体，从配置中心或环境变量加载：

type ABConfig struct {
  AWeight int `env:"AB_A_WEIGHT" default:"90"`
  BWeight int `env:"AB_B_WEIGHT" default:"10"`
}

• 权重总和不强制要求是 100，只要按比例算即可：if hash%100
• 中间件中调用分流函数时，传入 *http.Request 和当前配置快照，避免并发读写 config 变量
• 别在 http.HandlerFunc 内部直接写 if rand.Intn(100) —— 这不是 AB 测试，是流量抖动

遇到 sticky session 失效或 CDN 缓存污染要主动透传分组信息

当用户请求经过 Nginx、CDN 或负载均衡器时，原始请求头可能被清洗，导致分流中间件拿不到真实 user_id 或 cookie，结果所有流量都落到同一组。

• 确保反向代理转发时保留关键 header，例如 Nginx 配置里加：proxy_set_header X-User-ID $cookie_user_id;
• CDN 缓存键（Cache Key）必须包含分流依据字段，否则 A 组页面可能缓存后返回给 B 组用户
• 前端 JS 若也参与分流（如埋点打标），需和服务端哈希逻辑一致，否则上报数据与后端记录错位

上线前必须验证分流均匀性，而不是只看日志有没有报错

日志里没报错 ≠ 分流正确。常见问题是哈希碰撞集中、权重计算溢出、或字符串编码不一致（比如 UTF-8 和 GBK 下同一用户名哈希值不同），导致实际流量倾斜严重。

• 上线前用历史 user_id 列表跑离线模拟：统计 10 万 ID 的分组分布，偏差超过 ±2% 就得查哈希实现
• 线上加一个 debug 接口（带权限控制），返回当前请求的哈希值、取模结果、最终分组，方便快速排查单个 case
• 监控维度至少包括：每分钟各组请求数、各组 UV、各组转化率；如果某组 UV 突降，大概率是分流标识丢失或哈希异常

真正难的不是写几行哈希代码，而是让整个链路里每个环节都尊重同一个用户标识，并在变化时保持行为可预测。漏掉任意一环，AB 数据就废了。

今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~