用hashlib对稳定用户标识哈希取模实现分流，必须服务端计算并透传ab_group，前端仅辅助埋点且需校验一致性。
怎么用 hashlib 做稳定用户哈希分流
哈希分流不是随机分，核心是「同一用户每次请求都落到同一个实验组」。靠 hashlib.md5 或 hashlib.sha256 对用户标识（比如 user_id 或 device_id）做哈希，再取模定组别，最简单也最可靠。
常见错误是直接用 random.random() 或时间戳生成分组——这会导致用户刷新页面就换组，实验数据完全不可信。
- 必须用确定性哈希函数，不能依赖运行时状态
- 输入要包含唯一且稳定的用户标识；避免用会变的字段如
session_id - 取模前建议用
int(hash_obj.hexdigest()[:8], 16)转成整数，比直接对整个 hex 字符串取模更均匀 - 如果实验组数是 2 的幂（如 4、8），可用位运算
& (n-1)替代% n，性能略好但非必需
import hashlib
def get_ab_group(user_id: str, n_groups: int = 2) -> int:
h = hashlib.md5(user_id.encode()).hexdigest()
return int(h[:8], 16) % n_groups
为什么不能只靠前端 JS 做分流和埋点
前端分流看似方便，实则破坏实验一致性：用户禁用 JS、CDN 缓存静态页、服务端 SSR 渲染时未同步分组，都会导致同个用户在不同端看到不同版本，甚至同个页面两次加载分到不同组。
埋点也一样——如果只在前端发 fetch 上报，网络失败、用户快速关闭页面、AdBlock 拦截都会造成数据丢失，且无法验证分流逻辑是否真被执行。
立即学习“Python免费学习笔记（深入）”；
- 分流必须在服务端完成（如 Django middleware、Flask before_request、或网关层），确保响应内容与分组严格对应
- 关键埋点（如「进入实验页」「点击按钮」）需服务端记录一次，前端再补发一次（双写），用于交叉校验
- 前端埋点 payload 中必须带上服务端下发的
ab_group和experiment_id，不能自己算
ab_group 字段该存在哪？数据库 vs Redis vs HTTP Header
分流结果不是临时变量，它要贯穿请求生命周期，并被日志、埋点、下游服务共同消费。存在哪，取决于你读写的频次和一致性要求。
- 存在数据库用户表里？太重——每次请求都查库，还可能因事务延迟导致刚注册用户没及时写入
- 存在 Redis？适合高频读写，但要注意 key 设计（如
ab:user:{user_id}:exp_v2），并设好过期时间（建议 30 天以上） - 最常用的是存在请求上下文（如 Flask 的
g.ab_group）或注入到 HTTP Response Header（如X-AB-Group: 1），让前端和日志采集都能直接拿到 - 注意：Header 不能传敏感信息，且需确认 Nginx / CDN 不会过滤自定义 header
埋点日志里漏了 ab_group 怎么补救
上线后发现日志里没有实验分组字段，又没法重放流量，基本只能靠关联补全——前提是原始请求中至少保留了可追溯的用户标识和时间戳。
典型补救路径：从 Nginx access log 或 API 网关日志中提取 user_id + timestamp，调用和线上一致的哈希函数重新计算 ab_group，再按时间窗口（如 ±5 秒）关联到业务埋点日志。
- 必须确保补算用的哈希逻辑和服务端完全一致（包括编码、截取长度、模数）
- 时间窗口不能太大，否则会引入错配；也不能太小，否则漏匹配
- 如果原始日志连
user_id都没打（比如只打了匿名uuid），而这个uuid又不是分流用的 ID，那就基本无法回溯
真正难的不是写哈希函数，而是从第一个请求开始，就让分流、响应、埋点三者在数据层面咬合住。中间断一环，后面全是脏数据。
