接口服务里的 A/B Test：从灰度开关到可信实验

以前我对 A/B test 的第一反应也是前端：按钮颜色、落地页标题、价格页卡片。后来做接口服务多了，才发现更难的实验反而在后端。

搜索排序换一套策略，工具选择多加一个供应商，参数修复逻辑调得更激进，某个慢接口要不要提前降级，甚至一次缓存命中策略调整，都可能让成功率、延迟、成本和用户体验同时变化。上线前在测试环境跑通，只能证明它“能跑”。真正的问题是：它在真实流量里是不是更好？

如果只是开一个灰度比例，这件事还不算 A/B test。灰度能降低爆炸半径，但不能回答“新方案是否值得全量”。要回答这个问题，必须有稳定分组、真实曝光、结果归因、指标窗口和护栏。否则最后只会得到一堆看似漂亮、其实不能用的数据。

这篇写的是我现在更愿意采用的一套接口服务实验做法。不是某个项目复盘，也不贴工作里的代码，只讲可复用的架构判断。

灰度不是实验

Feature flag、灰度、A/B test 经常被放在一个后台里，但它们不是一回事。

Feature flag 管的是发布开关。代码已经部署，功能先不对所有人打开，这是它最基本的价值。

灰度管的是风险。先给 1% 流量，再给 5%、20%、50%，一边放量一边观察系统是否扛得住。

A/B test 管的是判断。它要比较新旧方案的效果，并且这个比较要尽量可信。可信这两个字很重，意味着实验单位不能乱、分组不能飘、曝光不能漏、结果不能对不上、指标不能临时改。

Unleash 的实验方案把 feature flag、变体和 impression data 串在一起，这个思路很工程化：开关负责交付，变体负责差异，曝光事件负责告诉分析系统“谁看到了什么”。Statsig 对 raw events 的说明也很清楚：曝光事件用来说明分组，自定义事件用来说明后续行为。两者缺一块，实验结果就很难读。

接口服务还有一个前端实验不太常见的问题：一次用户行为往往跨多个请求。用户先检索，再执行；先创建任务，再轮询结果；先拿报价，再确认购买。真正被实验影响的可能是第一个请求，但结果要到后面的请求才出现。如果中间没有把实验上下文带过去，后面的成功率和成本就归不到正确的变体上。

我会把实验层放在业务逻辑前面

一个后端实验系统，不应该散落在业务代码里。比较稳的形态，是在请求进入业务逻辑之前先生成一个“实验上下文”。

请求带着用户、会话、API key、站点、环境、地域等信息进入实验层。实验层只做四件事：找出正在运行的实验，判断这个请求是否符合目标人群，按稳定规则分桶，返回本次请求应该使用的配置。业务逻辑只消费配置，不直接关心分桶细节。

这个拆法的关键，是让实验层保持通用。它不需要知道业务是在做搜索、支付、推荐还是文档处理。它只认识这些概念：