AB分流必须用稳定哈希（如crc32($key) % 组数），禁用rand()；指标需用户去重、t检验p值+Wilson置信区间；配置须中心化管理，SQL标签严格一致。
AB分流必须用稳定的哈希，别直接 rand()
用
或
做分流，用户每次刷新页面都可能换组，实验数据完全不可信。核心是「同一用户、同一实验、长期固定分组」，得靠可复现的哈希。
实操建议：
立即学习
“
PHP免费学习笔记（深入）
”；
用用户唯一标识（如
或脱敏后的
）拼接实验名，例如
用
或
计算哈希值，再对组数取模：
得 A/B 组（0 或 1）
避免用
—— PHP 默认返回十六进制字符串，转整数易溢出或截断，
返回 int 更稳
如果需要多组（比如 A/B/C），确保模数和实际组数严格一致，别写成
却只配了两组配置
指标计算不能只看均值，要盯住 p 值和置信区间
上线后看到「转化率从 5.2% → 5.8%，涨了 11.5%」就宣布成功？大概率是噪声。PHP 后端通常只负责埋点和聚合原始数据，但评估逻辑必须防伪。
实操建议：
立即学习
“
PHP免费学习笔记（深入）
”；
关键指标（如点击率、支付成功率）必须按用户维度去重统计，避免同一个用户多次行为拉高分母
用
或
（需启用 stats 扩展）算 t 检验 p 值；没扩展就调用 Python 脚本或用 SQL + 窗口函数预计算
置信区间推荐用 Wilson 分数区间（适合小样本二项分布），别硬套正态近似——尤其当转化率
漏斗类指标（如浏览→加购→下单）要分层检验，不能只看最终环节；中间某步显著下降，可能掩盖了新功能的真实问题
分流开关和指标口径必须集中配置，禁止硬编码
把
写死在代码里，改个流量比例就得发版，还容易不同服务读到不同版本。
实操建议：
立即学习
“
PHP免费学习笔记（深入）
”；
用中心化配置中心（如 Consul、Apollo）或数据库表存实验元信息：
、
、
、
分流逻辑封装成独立 Service 类，构造时传入配置，避免全局变量或静态方法污染上下文
所有指标计算 SQL 必须包含明确的实验标签字段（如
），且该字段值与分流时完全一致——常见坑：分流用
，但日志里存的是字符串 "A" / "B"，大小写或空格不一致导致 join 失败
上线前跑一次影子比对：用历史数据模拟分流，验证各组样本量偏差是否
PHP 日志里必须打全分流上下文，否则排查归因失败
只记
不够。当发现 B 组支付失败率突增，你得快速确认：是不是只影响 iOS？是不是仅限优惠券场景？有没有和其他实验叠加？
实操建议：
立即学习
“
PHP免费学习笔记（深入）
”；
每条 AB 相关日志至少含：
、
、
、
（分流算法版本）、
（用于复现哈希）
关键业务日志（如
）必须带上
字段，JSON 格式，方便 ES 或 ClickHouse 提取分析
别依赖前端传来的
—— 容易被篡改或丢失，PHP 层必须自己重新计算并校验一致性
灰度阶段先打 debug 日志，确认分流逻辑稳定运行 24 小时以上，再切到 info 级别
最麻烦的从来不是写分流代码，而是保证「分流逻辑、日志字段、指标 SQL、配置更新」四者时刻对齐。任何一个环节滞后或错位，实验结论就失效，而且很难事后回溯。
rand()mt_rand()user_iddevice_id"user_12345:checkout_v2"md5()crc32()crc32($key) % 2hash('sha256', ...)crc32()% 3stats_cdf_t()stats_dens_t()$exp_config = ['checkout_v2' => ['A' => 0.5, 'B' => 0.5]]experiment_namegroup_ratiostart_timemetric_sqlab_groupcrc32"user_id=12345 ab_group=B"user_idab_experimentab_groupab_versionab_seedorder_createdab_contextab_group