以前我对 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、站点、环境、地域等信息进入实验层。实验层只做四件事：找出正在运行的实验，判断这个请求是否符合目标人群，按稳定规则分桶，返回本次请求应该使用的配置。业务逻辑只消费配置，不直接关心分桶细节。这个拆法的关键，是让实验层保持通用。它不需要知道业务是在做搜索、支付、推荐还是文档处理。它只认识这些概念：概念作用实验一次可开关、可暂停、可结束的比较作用域这次实验影响哪个服务或接口族目标人群哪些用户、环境、地域、标签可以进入流量比例总共有多少符合条件的主体进入实验变体control