Feature Flag 与渐进式发布

部署不等于发布

部署把代码放入生产环境，发布决定用户何时能使用功能。Feature Flag 可以解耦二者，让团队先部署不可见代码，再按用户、组织、地区或比例逐步开放。

开关不是权限系统。前端隐藏功能只能改善体验，服务端必须独立校验权限和规则。

开关类型

• Release Flag：控制未完成或渐进发布的功能，应短期存在。
• Experiment Flag：用于实验分组，需要稳定分桶和统计设计。
• Ops Flag：在故障时关闭高成本或不稳定能力。
• Permission Flag：表达套餐或授权，通常寿命更长且必须由服务端负责。

不同类型的负责人、默认值、审计和清理周期不同，不应都塞进一个布尔配置文件。

评估位置

服务端评估更适合安全、稳定分组和 SSR 一致性；客户端评估可以快速响应本地上下文，但规则和配置对用户可见。SSR 与客户端必须得到一致结果，否则会产生界面闪烁或 Hydration 不一致。

失败策略

配置服务不可用时，应为每个开关定义 fail-open 或 fail-closed。关键安全和付费能力通常宁可关闭；非关键视觉实验可以回到稳定默认值。缓存配置还需定义最大陈旧时间。

生命周期

每个开关至少记录所有者、创建时间、目的、默认值、目标删除日期和关联任务。发布完成后删除旧分支与测试，而不是只在平台关闭开关。长期累积的组合会让测试状态指数增长。

实践任务

1. 用 Release Flag 控制新版编辑表单，按内部用户、10%、50%、100% 放量。
2. 在每个阶段观察错误率、业务成功率和性能。
3. 演练配置服务不可用与一键关闭。
4. 全量稳定后删除开关和旧实现。

验收标准

• 部署后可以不重新构建就调整发布范围
• 分桶对同一用户保持稳定
• 服务端独立执行权限校验
• 监控事件包含开关变体和发布版本
• 开关有所有者、到期日和删除记录