如何解决A/B测试数据分组问题？使用Composer引入实验测试组件就可以！

Composer只是PHP依赖管理工具，不能直接解决A/B测试分组问题；必须用稳定用户标识（如userId）配合确定性哈希，并手动持久化结果，否则同一用户会反复变组。

先说一个核心事实：Composer 是 PHP 的依赖管理工具，它本身并不提供 A/B 测试的逻辑，更谈不上能“直接解决”数据分组这个核心难题。引入一个实验组件，比如 splitbrain/phpab 或者自研的 SDK，仅仅是万&里长征的第一步。真正的硬骨头——分组逻辑的设计、用户一致性的保障、实验状态的持久化——全都得靠开发者自己来设计和验证。

为什么 composer require 后分组还是乱的？

你是不是也遇到过这种场景？同一个用户刷新页面，getVariation() 返回的结果在 A 和 B 之间反复横跳；或者用户换个设备登录，分组结果就变了样。

• 问题的根子在于，很多轻量级组件为了图方便，默认会依赖 session_start() 或者内存缓存来做分组决策。但问题随之而来：session 可能根本没开启、会在跨请求时丢失，或者缓存一旦没命中，系统就会重新进行一次哈希计算。
• 这里有个铁律：分组必须满足「同一用户 + 同一实验」的组合，始终返回相同的变体。要实现这一点，离不开两个要素：一个稳定的输入（比如用户 ID、设备 ID、登录态 token）加上一个确定性的哈希算法（例如 md5($userId . $experimentKey)）。
• 所以，千万别想当然地依赖组件内置的“随机分配”，除非你明确配置了它的 sticky 模式，并且传入了那个稳定的 key。

splitbrain/phpab 的 getVariation() 怎么用才不翻车？

以这个常用库为例，它的默认行为其实有点“坑”：每次调用都可能给出不同的结果，这绝不是你想要的、开箱即用的 A/B 分组方案。

• 关键一步：必须手动传入一个唯一且稳定的 $userKey。代码应该写成这样：$ab->getVariation('checkout_button', $userId)。如果省略这个参数，库就会默默 fallback 到简单的 rand() 函数。
• 同时，要确保 $userId 在用户未登录时也有降级策略。比如，可以回退到使用 $_COOKIE['device_id']，或者对 $_SERVER['REMOTE_ADDR'] 和 $_SERVER['HTTP_USER_AGENT'] 进行哈希组合。当然，采用这些方式时必须注意隐私合规的要求。
• 这个库本身不会自动存储和读取分组结果。你需要配合 $_SESSION 或 Redis 等持久化存储，自己写一层包装逻辑。例如：

  if (!isset($_SESSION['ab'][$experiment])) {
      $_SESSION['ab'][$experiment] = $ab->getVariation($experiment, $stableKey);
  }
  return $_SESSION['ab'][$experiment];

分组逻辑写在中间件还是业务层？

把分组逻辑写在中间件里，看起来能统一处理，很优雅，但实际上却容易埋下隐患。

• 试想一下：如果中间件提前执行了分组，并把结果塞进了 $request->attributes。但后续流程中，某个步骤可能因为异常跳过了这个中间件（比如 API 路由未匹配、被 CORS 预检请求拦截），那么业务代码里拿到的分组值，就可能是空的，甚至是旧数据。
• 更稳妥的做法是，在真正需要变体的业务点（比如渲染那个按钮之前）才去调用分组函数。并且，要把 $stableKey 和 $experimentKey 作为参数显式地传进去，避免任何隐式的上下文依赖。
• 最后，务必加上 fallback 机制：当分组服务不可用时（比如 Redis 超时、哈希函数报错），系统应该返回一个默认变体（比如 A），同时记录告警日志，而不是直接抛出异常导致整个流程中断。

说到底，A/B 测试的分组绝不是“引入一个包就完事”那么简单。从哈希算法的选型、用户标识 key 的稳定性，到存储介质的一致性读写、灰度开关的隔离粒度，每一个环节出了问题，都可能导致整个实验结论失效。而最常被忽略的一点是：没有在日志里打上 $stableKey 和实际的分组结果。一旦线上出了问题，排查起来根本无法还原用户的完整路径，那才叫真正的抓瞎。