ab测试分流必须基于稳定哈希，同一用户始终命中同一组；应使用user_id等业务主键哈希后取模，避免随机数或ip导致数据失真；分流权重须动态配置，不可硬编码。
分流逻辑必须基于稳定哈希，不能用随机数
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）必须可动态配置，否则每次改比例都要发版。硬写死在中间件里等于把策略和逻辑耦合在一起，运维无法灰度调整。
建议把分流配置抽成结构体，从配置中心或环境变量加载：
立即学习“go语言免费学习笔记（深入）”；
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 数据就废了。
