Title: 功能开关与 A/B 测试
Locale: zh
URL: https://sensorswave.com/docs/feature-gates/gates-vs-experiments/
Description: 了解功能开关和 A/B 测试的区别、使用场景和配合方式
功能开关和 A/B 测试是两个容易混淆的概念。本文详细说明两者的区别、各自的使用场景，以及如何配合使用。

## 核心区别

### 设计目的不同

**功能开关（Feature Gate）**：
- 控制功能的开启和关闭
- 管理功能发布的节奏
- 实现精准的用户定向

**A/B 测试（Experiment）**：
- 对比不同方案的效果
- 通过数据验证假设
- 优化产品决策

### 关注点不同

**功能开关关注**：
- 功能是否稳定
- 是否影响系统性能
- 用户体验是否正常

**A/B 测试关注**：
- 哪个方案效果更好
- 指标提升是否显著
- 投入产出比如何

## 详细对比

| 对比维度 | 功能开关 | A/B 测试 |
|---------|---------|---------|
| **主要目的** | 控制功能上线，降低风险 | 验证功能效果，优化决策 |
| **使用时机** | 功能开发完成，准备上线 | 功能稳定后，验证效果 |
| **分组方式** | 基于用户属性、分群、百分比 | 随机分组，确保对比公平性 |
| **分组稳定性** | 可以随时调整 | 实验期间保持稳定 |
| **数据分析** | 基础使用统计 | 完整的指标对比和显著性检验 |
| **决策依据** | 技术指标（稳定性、性能） | 业务指标（转化率、留存率） |
| **生命周期** | 临时开关在全量后删除 | 实验结论后下线 |
| **配置复杂度** | 简单（开/关） | 复杂（多变体、指标、假设） |
| **典型场景** | 新功能发布、功能降级、权限控制 | 方案对比、优化验证、效果评估 |

## 何时使用功能开关

### 适用场景

#### 1. 新功能灰度发布

**目标**：验证功能的技术稳定性

**示例**：
- 新推荐算法上线
- 新支付方式集成
- UI 改版发布

**关注指标**：
- 错误率
- 响应时间
- 崩溃率
- 基本使用情况

#### 2. 功能降级保障

**目标**：在系统异常时快速降级

**示例**：
- 系统负载过高时关闭推荐系统
- 第三方服务故障时使用降级方案
- 大促期间临时关闭非核心功能

#### 3. 权限和功能控制

**目标**：不同用户看到不同功能

**示例**：
- 付费用户享有高级功能
- VIP 用户看到专属功能
- 地区定制功能

#### 4. 长期功能切换

**目标**：长期存在的功能开关

**示例**：
- 新旧版本切换
- 可选功能开关
- 实验性功能

### 使用建议

- **重点关注**：功能稳定性、技术指标
- **灰度策略**：逐步扩大，快速回滚
- **清理策略**：临时开关在全量后应删除

## 何时使用 A/B 测试

### 适用场景

#### 1. 方案效果对比

**目标**：找出最优方案

**示例**：
- 两种推荐算法哪个效果更好
- 两种定价策略哪个收入更高
- 两种 UI 设计哪个转化更好

**关注指标**：
- 转化率
- 留存率
- 人均消费金额
- 用户满意度

#### 2. 产品优化验证

**目标**：验证优化假设

**示例**：
- 缩短结账流程是否提升转化
- 增加推荐位是否提升点击
- 简化注册流程是否提升注册率

#### 3. 增长实验

**目标**：找到增长机会

**示例**：
- 优惠券策略优化
- 推送文案优化
- 营销活动效果评估

### 使用建议

- **重点关注**：业务指标、数据显著性
- **实验设计**：随机分组、样本量充足
- **决策依据**：统计显著性检验结果

## 决策流程

### 如何选择？

按照以下问题依次判断：

#### 1. 功能是否已验证稳定？

- **否** → 使用功能开关
  - 先通过功能开关验证技术稳定性
  - 渐进式灰度发布
  - 确认无技术问题后再考虑 A/B 测试

- **是** → 继续下一步

#### 2. 是否需要对比多个方案？

- **否** → 使用功能开关
  - 没有对比方案，只是上线新功能
  - 使用功能开关控制发布节奏

- **是** → 使用 A/B 测试
  - 需要对比两个或多个方案的效果
  - 通过数据选择最优方案

#### 3. 是否需要统计显著性验证？

- **否** → 使用功能开关
  - 不需要严格的数据验证
  - 基于经验或用户反馈决策

- **是** → 使用 A/B 测试
  - 需要数据支持决策
  - 需要统计显著性检验

### 决策树

```
新功能准备上线
    ↓
功能是否稳定？
    ├─ 否 → 功能开关（灰度验证稳定性）
    └─ 是 → 是否需要对比方案？
            ├─ 否 → 功能开关（控制发布）
            └─ 是 → A/B 测试（验证效果）
```

## 配合使用

> **我们的推荐**：功能开关和 A/B 测试配合使用，效果最佳。先用功能开关验证技术稳定性，再用 A/B 测试验证业务效果。

### 使用流程

#### 阶段 1：功能开关验证稳定性

**目标**：确保功能技术上可行

**步骤**：
1. 创建功能开关
2. 内部测试（0.1%）
3. 小范围灰度（1%）
4. 逐步扩大（10% → 50%）
5. 验证技术指标

**关注指标**：
- 错误率  99%
- 错误率 < 0.5%

**第二步：A/B 测试验证效果**

功能开关全量后，创建 A/B 测试：

```javascript
// 检查功能开关
const isNewCheckoutEnabled = await SensorsWave.checkFeatureGate(
  'new_checkout_flow_enabled'
);

if (!isNewCheckoutEnabled) {
  renderLegacyCheckout();
  return;
}

// 功能已开启，进行 A/B 测试
const experiment = await SensorsWave.getExperiment(
  'checkout_flow_optimization'
);
const variant = experiment?.variant || 'control';

if (variant === 'treatment') {
  // 实验组：新结账流程
  renderNewCheckout();

  // 追踪实验事件
  SensorsWave.trackEvent('CheckoutStarted', {
    experiment: 'checkout_flow_optimization',
    variant: 'treatment',
    flow_version: 'v2'
  });
} else {
  // 对照组：旧结账流程
  renderLegacyCheckout();

  // 追踪实验事件
  SensorsWave.trackEvent('CheckoutStarted', {
    experiment: 'checkout_flow_optimization',
    variant: 'control',
    flow_version: 'v1'
  });
}
```

**实验配置**：
- 流量分配：50% vs 50%
- 实验周期：2-4 周
- 最小样本量：1000 次转化（每组）

**验证指标**：
- 主要指标：支付转化率
- 次要指标：平均订单金额、结账时长

**第三步：全量发布**

A/B 测试结果显著，新流程转化率提升 8%：

1. 停止 A/B 测试
2. 移除代码中的实验判断
3. 所有用户使用新流程
4. 稳定运行 1-2 个月后清理功能开关

### 配合收益

**相比只用功能开关**：
- ✅ 有数据支持决策
- ✅ 知道提升幅度
- ✅ 可以计算 ROI

**相比只用 A/B 测试**：
- ✅ 技术风险可控
- ✅ 可以快速回滚
- ✅ 问题影响范围小

## 常见误区

### 误区 1：功能开关可以替代 A/B 测试

**错误认知**：
"我用功能开关分了两组用户，看看哪组数据更好，不就是 A/B 测试吗？"

**为什么错误**：
- 功能开关的分组不是随机的，可能有偏差
- 缺少统计显著性检验，可能得出错误结论
- 没有对照组，无法排除外部因素影响

**正确做法**：
- 功能开关用于控制发布
- A/B 测试用于效果验证
- 两者配合使用

### 误区 2：A/B 测试可以替代功能开关

**错误认知**：
"我直接用 A/B 测试发布新功能，不需要功能开关。"

**为什么错误**：
- A/B 测试期间，如果功能有问题，无法快速回滚所有用户
- A/B 测试通常需要稳定运行 2-4 周，问题影响时间长
- A/B 测试设计更复杂，不适合简单的功能开关场景

**正确做法**：
- 先用功能开关验证稳定性
- 再用 A/B 测试验证效果

### 误区 3：所有功能都需要 A/B 测试

**错误认知**：
"每个新功能都应该做 A/B 测试。"

**为什么错误**：
- A/B 测试有成本（时间、资源、复杂度）
- 有些功能明确更好，不需要测试
- 有些功能是必须的，没有对比方案

**正确做法**：
- 只对有对比方案的功能做 A/B 测试
- 明确更好的功能，用功能开关发布即可

## 实践建议

### 功能开关的使用原则

**推荐做法**：
- 新功能都应该用功能开关
- 先验证稳定性，再考虑效果
- 临时开关在全量后应删除

**避免的做法**：
- 不要用功能开关做 A/B 测试
- 不要跳过灰度直接全量
- 不要累积过多无用的开关

### A/B 测试的使用原则

**推荐做法**：
- 明确假设和预期效果
- 确保随机分组和样本量充足
- 基于统计显著性做决策

**避免的做法**：
- 不要在功能不稳定时做 A/B 测试
- 不要过早结束实验
- 不要忽视统计显著性

## 下一步

现在您已经了解了功能开关和 A/B 测试的区别和配合方式，接下来可以：

**深入学习 A/B 实验**：
1. **[A/B 实验概述](../experiments/overview.mdx)**：了解 A/B 实验的核心能力
2. **[快速开始](../experiments/quick-start.mdx)**：20 分钟完成第一个 A/B 实验
3. **[SDK 集成](../experiments/sdk-integration.mdx)**：在代码中集成 A/B 实验

**继续学习功能开关**：
1. **[管理功能开关](management-and-monitoring.mdx)**：学习如何管理功能开关
2. **[最佳实践](best-practices.mdx)**：掌握功能开关的最佳使用方法
3. **[常见问题](faq.mdx)**：查看常见问题的解答

---

**最后更新时间**：2026 年 1 月 29 日