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