分流必须基于确定性哈希，输入相同则输出恒定整数；推荐 go 1.21+ 的 hash/maphash，全局复用 seed；key 应排除实验名，多维度分流需 bucketkeygenerator 接口抽象；非均等权重须用前缀和匹配。
分流决策必须基于确定性哈希，不能用 rand.Intn
同一用户反复请求必须落到同一实验组，否则点击率、转化率等指标完全失真。用 rand.Intn 或 time.Now().UnixNano() 做判断，服务重启后分组全乱，历史数据断层，也无法复现问题。
真正可用的分流逻辑必须满足：输入相同（如 user_id、device_id 或标准化后的 query），输出永远一致整数。Go 1.21+ 推荐直接用 hash/maphash，它比 crypto/md5 快一个数量级，又比 fmt.Sprintf + sum64 更抗碰撞。
- 全局复用同一个 seed：
var globalSeed = maphash.MakeSeed()，每次调用前h.SetSeed(globalSeed)，别在 handler 里反复 new -
user_id是int64？别用strconv.FormatInt(id, 10)再哈希——负数、前导零会导致字节序列不一致；改用binary.PutVarint(h, &id) - 哈希输入里不要拼实验名（如
"search_v2:" + userID）——后续扩组或调比例时哈希值全变，用户重分桶；实验名应作为独立参数传入，不参与哈希计算
多维度分流需抽象 BucketKeyGenerator 接口
不同场景要依据不同 key 分流：搜索 AB 看 user_id + query，灰度发布看 service_version + region，AI 模型实验看 request_id + model_name。硬编码一堆 if-else 会迅速失控。
正确做法是定义接口统一入口：
type BucketKeyGenerator interface {
Generate(r *http.Request) string
}
然后按需实现：
-
UserQueryKey：拼接userID和归一化后的query（去空格、小写、截断） -
VersionRegionKey：取r.Header.Get("X-Service-Version") + "-" + r.Header.Get("X-Region") -
RequestModelKey：用traceID和模型标识构造，确保单次推理请求恒定分组
中间件调用时只关心 key := generator.Generate(r)，后续哈希、权重匹配全部复用同一套逻辑，避免重复造轮子。
非均等权重必须用前缀和匹配，别用 % 取模
想实现 17%/50%/33% 的三组分流，写 hash.Sum64() % 3 或 hash.Sum64() % 100 都会引入分布偏差——尤其当哈希低位周期性弱、或用户集较小时（比如只测内部员工 2000 人），某组可能长期无命中。
正确方式是算总权重，再做前缀和线性匹配：
weights := []int{17, 50, 33}
total := 100
h := hash.Sum64() % uint64(total)
acc := 0
for i, w := range weights {
acc += w
if int(h)
- 权重必须为整数，别用
float64——Go 中浮点取模有精度误差，千万级请求下偏差可超 ±3% - 加新组或调比例，只需改
weights切片，无需动分支逻辑 - 总和不必是 100，但建议控制在合理范围（如 ≤ 10000），避免
uint64溢出
显式分组优先级必须明确，且支持透传与日志打标
线上调试、运营强制指定、A/B 对比验证都需要人工干预能力。分流决策必须按明确优先级执行，不能靠“运气”或随机 fallback。
推荐顺序（从高到低）：
- 先读
X-Ab-Groupheader —— 运营可手动设置，用于紧急回滚或定向验证 - 再查
ab_groupcookie（带签名）—— 前端埋点或用户主动选择 - 最后 fallback 到哈希计算 —— 基于
BucketKeyGenerator输出的 key
关键动作不能少：
- 把最终分组写入
ctx.Value("ab_group")，并注入下游X-Ab-Groupheader，确保链路透传 - 记录日志字段：
ab_group=v2、ab_rule=hash_user_query、ab_salt_ver=2，否则事后无法归因 - 响应头务必加
Cache-Control: private，防止 CDN 缓存污染导致 A 组页面返回给 B 组用户
最易被忽略的是 key 归一化细节：同一个搜索词，前端传 "iPhone"，后端解析成 "iphone "（带空格），哈希结果就不同——所有归因分析都会失效。必须在 BucketKeyGenerator 实现里统一 trim、lower、normalize。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
