3. Feature Flag 基础：Flag 类型与生命周期
Feature Flag（特性开关）是现代云原生架构中实现渐进式发布、实验驱动开发和精细化权限控制的核心基础设施。本章从 Flag 的三种基本类型出发，深入剖析其生命周期管理，为后续变更冻结闸口与自动化参数调优奠定基础。
3.1 Flag 类型：发布开关、实验开关、权限开关
根据使用场景与决策逻辑，Feature Flag 可划分为三大类型。下表从核心用途、决策维度、典型变更频率三个角度进行对比：
| 类型 | 核心用途 | 决策维度 | 典型变更频率 | 示例 |
|---|---|---|---|---|
| 发布开关 | 控制功能上线/下线的二进制闸门 | 环境、时间、全局百分比 | 低（周/月级） | new_checkout_flow |
| 实验开关 | 分配用户到不同实验组，收集指标 | 用户 ID、随机分桶、属性 | 高（天/小时级） | recommendation_v2 |
| 权限开关 | 按角色/租户/灰度名单授予功能访问 | 用户角色、组织、IP 段 | 中（周级） | admin_dashboard |
3.1.1 发布开关（Release Toggle）
发布开关是最基础的 Flag 类型，本质是一个布尔值闸门。它通常与 CI/CD 流水线集成，在预发环境验证通过后，通过开关将新功能暴露给生产环境的部分或全部流量。发布开关的典型生命周期为：创建 → 预发开启 → 生产灰度 → 全量开启 → 废弃。
最佳实践：发布开关应尽量短命（通常不超过 2 个迭代周期），避免形成“开关债务”。每次全量发布后，应立即清理对应的 Flag 代码。
3.1.2 实验开关（Experiment Toggle）
实验开关用于多变量测试（A/B/n 测试）。它根据用户标识或随机分桶将流量切分到不同实验组，并关联埋点与指标系统。实验开关的决策逻辑通常包含：
- 分桶算法：一致性哈希（如 MurmurHash）确保用户始终进入同一实验组。
- 流量分配：支持百分比、用户属性、地域等条件。
- 指标绑定：每个实验组关联核心业务指标（如转化率、延迟 P99）。
3.1.3 权限开关（Permission Toggle）
权限开关用于细粒度访问控制，常见于多租户 SaaS 平台或内部工具系统。它不依赖随机概率，而是基于用户上下文（角色、组织、标签）进行决策。权限开关的典型配置结构如下：
{
"flag": "beta_feature_x",
"rules": [
{"condition": "user.role == 'admin'", "value": true},
{"condition": "user.tenant == 'enterprise'", "value": true},
{"condition": "user.id in whitelist", "value": true},
{"default": false}
]
}
类型选择建议：若 Flag 仅用于上线/下线，优先使用发布开关；若需要验证假设，使用实验开关；若控制谁能用，使用权限开关。混合使用时应保持语义清晰，避免一个 Flag 同时承担多种职责。
3.2 Flag 生命周期
Feature Flag 从创建到废弃的完整生命周期包含六个阶段。每个阶段都有明确的输入、操作和输出，忽视任何阶段都可能导致技术债务或线上事故。
| 阶段 | 核心活动 | 关键角色 | 常见风险 |
|---|---|---|---|
| 1. 设计 | 定义 Flag 名称、类型、默认值、目标受众 | 开发 + PM | 命名不规范，类型选择错误 |
| 2. 创建 | 在管理平台注册 Flag，配置初始规则 | 开发 | 缺少描述与负责人 |
| 3. 评估 | SDK 拉取配置，根据上下文返回 Flag 值 | 运行时 | 缓存过期、配置不一致 |
| 4. 变更 | 调整 Flag 规则（灰度比例、实验分组） | SRE / 开发 | 未走审批、变更未记录 |
| 5. 观测 | 监控 Flag 影响面、错误率、性能指标 | SRE / QA | 指标缺失、告警阈值不合理 |
| 6. 废弃 | 移除 Flag 代码与配置，清理历史数据 | 开发 | 遗留代码导致维护成本 |
3.2.1 生命周期中的关键决策点
在 Flag 的整个生命周期中，有三个决策点直接影响系统稳定性与可维护性：
- 创建时：必须指定 Flag 的预期存活时间（TTL）。超过 TTL 未废弃的 Flag 应触发告警。
- 变更时：灰度比例变更应遵循“小步快跑”原则，每次增量不超过 10%，并观察至少 5 分钟。
- 废弃时：先关闭 Flag（设为 false），等待 2 个完整部署周期确认无影响后，再删除代码与配置。
⚠ 常见陷阱：“永久 Flag”是最大的技术债务来源。一个 Flag 如果超过 3 个月未被废弃，其维护成本将指数级上升。建议在 Flag 管理平台中设置自动过期提醒。
3.3 Flag 类型与生命周期的协同
不同类型的 Flag 在生命周期各阶段的关注点存在显著差异。下表总结了三种 Flag 在生命周期关键阶段的最佳实践：
| 生命周期阶段 | 发布开关 | 实验开关 | 权限开关 |
|---|---|---|---|
| 设计 | 命名包含环境后缀（如 _prod） |
绑定实验 ID 与指标定义 | 定义角色层级与继承关系 |
| 变更 | 走变更审批流程，记录变更原因 | 自动调整流量比例，避免人工干预 | 审计日志记录每次权限变更 |
| 废弃 | 全量开启后立即清理 | 实验结束后保留数据，删除 Flag | 权限下沉到代码后移除 Flag |
自动化参数调优前置知识：理解 Flag 类型与生命周期是后续实现“变更冻结闸口”的基础。例如，冻结期间仅允许权限开关变更，而发布开关和实验开关必须锁定。生命周期中的“废弃”阶段是自动化清理脚本的核心触发点。