特性开关是什么
特性开关（feature flag）把「代码合入主干」与「功能对用户放量」解耦：新功能随主干随时合入、默认关闭，通过灰度开关逐步放开。它是主干开发体系的常用组件，让主干保持可发布的同时降低上线风险。开关本身是临时债务，需要配套的清理计划。
基本信息
| 目的 | 解除部署与发布节奏的耦合，随时可关 |
|---|---|
| 粒度 | 功能级、用户级、百分比灰度 |
| 生命周期 | 临时开关设清理计划；长期开关按产品能力管理 |
| 风险 | 长期堆积形成两套代码路径的维护负担 |
| 回滚 | 关掉开关等于即时下线，不必回滚整个发布 |
典型使用场景
- 大型功能开发：多次小步合入主干，用户仍看不到未完成部分
- 灰度上线：先小比例用户、再逐步放量，用数据决定继续或回滚
- 紧急开关：线上故障时一键关掉可疑功能，不必回滚整个发布
- 按环境差异：内部环境全开、生产默认关
- 兼容性迁移：新旧实现并存一段时间，观察后删除旧路径
代码示意
代码示意
# 判断开关状态，默认关闭
if (flags.enabled('new-checkout')) {
renderNewCheckout(); # 新路径
} else {
renderLegacyCheckout(); # 旧路径，灰度期间保留
}
# 发布节奏：合入主干（默认关）→ 内部验证 → 按比例灰度放量开关治理要点
| 要点 | 做法 | 原因 |
|---|---|---|
| 默认值 | 默认关闭，按需开启 | 误放量的影响面最小 |
| 命名与登记 | 统一命名、登记负责人 | 欠账可见、有人负责 |
| 清理计划 | 创建时登记预计删除时间 | 避免两条路径长期并存 |
| 灰度度量 | 配套指标与回滚判据 | 没有数据无法判断是否继续放量 |
开关判断要有一致性：同一用户在不同服务与多次请求中看到的状态应稳定，按用户分桶而不是每次随机。
开关系统本身也是故障点：拉取开关的代码要有本地缓存与默认值兜底，开关服务不可用时不能把整个功能拖垮。