功能开关与渐进式交付把代码部署和功能开放分开

功能开关允许已部署代码在运行时选择不同路径，使团队可以先部署、后开放，按用户群逐步扩大，并在异常时快速关闭。渐进式交付把这一能力与监控、审批和回滚结合，用受控流量验证新行为。它缩短的是功能控制路径，不会消除数据库迁移、外部副作用和兼容性风险。

OpenFeature 提供厂商中立的功能开关评估规范，定义 provider、评估上下文、hook 和事件等概念：https://openfeature.dev/specification/category/sections/。规范统一应用调用方式，但规则存储、变更治理、隐私和可用性仍由具体系统承担。

开关类型决定生命周期和风险

发布开关用于短期隐藏未完成或待验证功能，成功后应删除旧路径。实验开关把稳定人群分配到不同变体，用于因果评估；运维开关在故障或容量压力下关闭高成本能力；权限开关则表达长期授权。若把这些用途都塞进一个布尔值，所有者、默认值和清理时机都会模糊。

开关不一定只有开和关。多变体配置可以选择算法版本、页面流程或限额档位，但变体越多，组合状态越难测试。关键开关应有明确名称、负责人、创建原因、默认行为、到期时间和依赖关系。临时发布开关过期后仍留在代码中，会形成难以理解的永久分支。

评估上下文通常包含用户、租户、区域、客户端版本或设备类型。只有来自可信身份链的属性才能用于安全决策；客户端可修改的字段不能承担权限控制。敏感属性应最小化传输和日志记录，规则界面也要限制谁能查看。

稳定分桶保证用户体验可重复

按百分比开放需要稳定哈希。相同主体在规则未变时应持续进入同一变体，否则用户会在新旧体验间跳动，实验结果也失去意义。哈希输入要选稳定身份，并加入开关专属盐，使不同实验不会把完全相同的人群绑定在一起。

规则优先级必须确定。内部测试名单、地区限制、版本条件和百分比分桶同时存在时，应能解释某个请求为何得到某个变体。评估结果最好携带变体、原因、规则版本和错误状态，供审计与诊断，但不要在普通日志中暴露完整用户属性。

无身份用户需要单独策略。随机请求级分配适合无状态性能试验，却不适合连续交互；匿名 cookie 可以稳定体验，但要遵守同意与保留政策。登录前后身份合并也会改变分桶，应提前规定。

配置故障要有确定的默认行为

开关服务不可用、超时或返回无效配置时，SDK 必须使用代码中声明的默认值。默认值应是可安全运行且向后兼容的路径，不能只是开发时随手填写。缓存最后一份有效配置可提高可用性，但需要版本、最大陈旧时间和紧急失效机制。

配置更新通常是最终一致的。不同实例在短时间内看到不同规则，因此涉及数据写入、协议格式或不可逆副作用的切换要设计双向兼容窗口。先让读取端兼容新旧格式，再逐步切换写入，最后清理旧路径。不能期待一个全局开关在所有进程中原子翻转。

钩子和事件便于记录评估、注入上下文或增加遥测，也可能给热路径增加延迟。外部网络调用不应放在每次评估中。评估缓存需要包含规则版本和相关属性，避免把一个租户的结果错误复用于另一个租户。

渐进放量必须绑定停止条件

放量可以从内部用户、单个测试租户或极小比例开始，再按预定阶段扩大。每一步都要观察错误率、尾延迟、资源使用和业务指标，并规定自动暂停或回退阈值。只看整体平均值会掩盖新功能集中影响的子群，因此指标需按变体和关键维度切分。

回退开关只能切断尚未发生的行为。已经写入新结构的数据、发出的消息和调用的外部接口需要补偿或向后兼容。上线计划应明确“关闭开关能恢复什么、不能恢复什么”，并在演练中验证。对安全修复也不能长期依赖隐藏开关，最终代码和配置都要收敛。

测试矩阵至少覆盖默认值、各变体、规则错误、配置陈旧和开关服务不可用。组合开关应限制数量，并为不允许的组合设置防护。发布完成后删除开关及旧实现，保留变更记录和实验结论。功能开关是一项运行时配置能力；只有稳定分桶、可信上下文、可观测放量和持续清理同时存在，才构成可靠的渐进式交付。

遥测要能回答某次评估为何发生

OpenTelemetry 的功能开关语义约定给出了评估事件与属性的统一方向：https://opentelemetry.io/docs/specs/semconv/feature-flags/。记录时应包含开关键、变体、provider 和评估原因，但避免写入姓名、邮箱或完整上下文。高频请求若每次都生成事件，会显著增加成本，可以使用聚合指标或采样，同时为错误评估和规则变更保留更完整证据。

业务指标与变体关联时，要使用稳定的实验分配标识，并处理用户跨设备、登录状态变化和机器人流量。观察到指标差异后还要检查样本比例失衡、曝光延迟和并发实验干扰。功能开关平台提供曝光机制，不自动形成可信实验。

清理是发布流程的一部分

每个短期开关应在创建时登记到期时间。功能全量稳定后，先确认旧路径无流量，再删除规则、代码分支、测试和监控；若保留“以防万一”，后续重构会同时维护两套行为。静态扫描可以找出代码引用，运行时数据则确认配置是否仍被评估，两者结合才能避免误删。

长期运维或权限开关不要求删除，但需要定期复核默认值、所有者和应急操作。没有负责人或无法说明用途的开关应视为配置债务，而不是安全缓冲。清晰的生命周期让渐进交付回到正常代码路径，降低下一次发布的组合复杂度。