功能开关（Feature Flag）

功能开关（Feature Flag，亦称 Feature Toggle）是一种控制软件某段行为是否启用、向哪些对象启用，或返回哪种配置值的机制。OpenFeature 的概念说明将最基本的功能开关概括为可在运行时控制的 if/else 判定，使应用行为能在不重新部署代码的情况下改变。工程团队在代码或配置中设置判定点，应用在运行时依据开关值决定走哪条逻辑路径。最简单的开关只有开启、关闭两种状态；多变体开关也可以返回字符串、数值或对象值。OpenFeature 的评估 API 文档列出布尔、字符串、数值与对象等不同类型的求值方法；AWS AppConfig 的官方说明则区分基础开关与多变体开关，后者可按请求上下文和规则返回不同取值，见其功能开关与配置数据文档。具体类型和配置形式依 provider 而异。

“开关”描述的是应用行为的控制方式，不是某一种产品、协议或唯一架构。有的团队把规则放在版本控制内的配置文件中，有的使用独立控制台或服务。评估位置也因实现而异：以 LaunchDarkly 文档所述架构为例，服务端 SDK 可在进程内使用缓存规则求值，客户端 SDK 则把评估请求交给服务端，见其客户端与服务端 SDK 说明；AWS AppConfig Agent 会异步轮询云端并在本机缓存配置，应用可向本地 Agent 读取数据，见Agent 工作方式。这些是具体产品实现示例，不是行业统一架构。OpenFeature 规范提供与开关管理后端解耦的评估 API 和 provider 接口，但不意味着不同后端的规则、传输方式或功能完全相同。选择或自建方案时，应核对 SDK 的评估位置、配置同步方式、缓存、离线行为和默认值。

一种常见实现包含四部分：代码中的判定点、可选的开关管理界面或配置源、负责求值的 SDK/provider，以及针对每次求值提供的上下文。上下文可以是用户、租户、设备、应用或服务的属性。规则根据上下文确定启用状态或取值；在按对象做百分比分配时，有些 provider 会使用 targeting key 来识别被分配对象。是否要求这个字段、缺少时如何处理以及分组是否稳定，取决于 provider 和其评估方式。OpenFeature 的评估上下文规范把 targeting key 定义为可选字段，同时说明某些 provider 可能要求它才能进行分数分配、规则匹配或用户覆盖。

开关值进入应用的路径因实现而异。以 LaunchDarkly 文档所述实现为例，服务端 SDK 在进程内用缓存规则求值；客户端 SDK 把评估请求交给服务端，并缓存评估结果供后续快速读取，见其客户端与服务端 SDK 说明。因此，本地求值要处理规则更新延迟和缓存；若某项实现把求值或结果更新交给远端服务，还需考虑网络可达性与请求延迟。客户端 SDK 也可能缓存结果，所以不一定每次应用读取都发起网络请求。开关服务断开时采用旧值、默认值还是停止某项功能，不能从通用概念推断，应按产品行为和功能风险设计并测试。若求值结果影响租户隔离、权限或敏感操作，仍应在服务端做可靠的授权判断；客户端隐藏按钮不等于访问控制。OWASP 的授权建议明确指出，客户端检查不能作为允许访问资源的决定因素，访问控制应由服务端、网关或 serverless 函数执行。

开关还可以按环境、组织、账户层级、地域、设备类型或其他适用属性设置目标，但这些条件不必全部采集。上下文中的个人信息会发送给开关后端或参与日志时，需确认数据用途、保存方式与访问范围，优先使用最少字段或可替代标识。OpenFeature 在评估上下文隐私说明中提醒，加入评估上下文的个人信息应结合 provider 如何处理和持久化数据来考虑。

功能开关可用于把代码部署与功能对用户开放分成两个决定：代码先进入运行环境，功能初始保持关闭或仅对限定对象开放，再由团队逐步扩大暴露范围。这让团队可先做内部验证、指定租户试用或小比例上线，并在观察异常时关闭相关路径。这里的“关闭”依赖应用的回退逻辑、规则传播和已有数据兼容，不能保证任何故障都能即时或无损回滚。

渐进式交付是一种逐步扩大变更影响范围并结合验证信号管理风险的交付做法，功能开关只是可采用的控制手段之一。渐进式交付也可以通过基础设施或平台层流量切分实现；Google Cloud Deploy 将 canary 部署描述为在旧版本仍运行时先把部分流量导向新版本，再按阶段扩大，并允许在阶段中使用指标分析来帮助判断是否推进，见Canary 部署策略说明。因此，依赖功能开关逐步开放“同一部署版本里的新功能”，与依赖部署系统逐步切换“新旧应用版本的流量”，控制对象并不相同，两种方式也可以组合。

LaunchDarkly 的文档进一步把固定百分比分流、随时间自动升高比例的渐进式 rollout、监测指标并可按规则停止或回退的 guarded rollout，以及对比多个变体的 experiments 列为不同的发布选项，见其功能发布选项比较。这属于该产品自己的功能分类，不能推成所有平台都采用同一命名或都提供自动回退。尤其要区分“比例逐步扩大”和“指标守护”：前者只说明暴露比例如何变化，不一定会自动检查服务健康；实际发布流程需明确观测指标、阈值、暂停条件和回退负责人。AWS AppConfig 文档展示了另一种产品实现：可用部署策略逐步发布配置，并在 CloudWatch 告警触发时自动回滚配置，见AppConfig 部署文档。这说明具体能力依服务配置和条件而定。

功能开关和 A/B 测试有关联，却不是同一概念。开关首先解决的是应用返回什么行为或配置值，以及目标对象如何匹配规则；A/B 测试则是一种比较方案，需要定义假设、对照和实验变体、分配对象、采集指标并解释结果。开关可以帮助稳定地把不同变体交给不同对象，也可以作为实验配置入口，但打开开关或观察一段时间并不会自动形成有效实验。

例如，团队可把新旧结账流程设为两个变体，按用户标识分组，并预先规定要比较的指标。经典 A/B 设计会把对象随机分配到对照与不同体验组，再依据采集到的遥测和预定目标比较结果；微软 PlayFab 的实验术语说明也这样描述其平台内的实验流程。此时开关承担分组和返回变体的功能，实验设计、曝光与指标事件、数据质量和统计解释决定能否回答“哪一种方案表现不同”这一问题。LaunchDarkly 的实验文档将选择指标、创建带变体的开关或配置、构建实验并开始实验周期列作分开的步骤，并提示目标上下文类型应与实验的随机化单位匹配，见创建实验的步骤。这些是产品文档描述的流程，也反映出变体路由与实验测量是不同工作。

相反，渐进式发布通常是风险控制：团队逐步把一个预定版本或功能交给更多对象，同时查看错误率、延迟、业务指标或支持反馈，目标是判断是否继续扩大、暂停或回退，而不必判断多个产品方案谁更好。若发布时同时改变受众、比例、功能逻辑和测量方式，单看前后数据就很难说明变化来自何处。发布验证与效果实验可以围绕同一开关衔接进行，但最好分别说明目标和方法。开关提供的是可控分流能力，不替代实验设计，也不能单凭观察结果证明因果关系。

在多租户 SaaS 中，功能开关可以用于将尚未全面推出的能力先开放给内部人员或受邀组织，也可以按客户计划、租户属性或地区配置不同功能。发布新界面、调整工作流、切换后台实现、引入第三方模型或分阶段开放高风险的新实现，都是可以考虑的场景；是否合适仍取决于授权规则、兼容性、测量能力与支持流程。组织或租户开关还可能带来合同、计费和支持预期，因此它不只是代码里的布尔值，也是一项需要明确所有者和变更记录的产品配置。

企业使用者通常需要区分几类状态：代码是否已部署、开关是否启用、哪些租户符合条件、外部服务是否可用，以及账户本身是否具有使用权限。比如客户套餐决定的功能权益，应由可靠的服务端权限逻辑判定，开关可控制新能力的逐步上线，但不能用客户端开关代替租户鉴权。处理数据迁移或外部 API 切换时，还需确认旧新格式兼容、任务是否可重入，以及回退之后已写入的数据如何处理。

功能开关能降低部分发布风险，也会引入代码分支、配置状态和协作复杂度。Pete Hodgson 在 Martin Fowler 网站刊载的技术文章按用途区分发布、实验、运维和权限开关，并指出功能开关会增加验证复杂度，多个开关可能组合出大量状态；这是工程实践文章中的分析，不是跨产品统一标准。

作为本文的维护建议，团队可为每个开关记录用途、负责人、创建时间和预期清理条件；完成发布后再评估是否删除临时开关。命名含糊、缺少维护责任或临时开关长期保留，也可能使测试、排障和理解实际运行路径变难。

按用途看，有的开关只为把新功能与代码部署拆开，发布后可清理；有的帮助应对运行故障，可能保留为运维开关；有的按对象决定某项功能是否可用，也可能是长期配置；实验开关则应尽量保持分组和配置稳定到测量完成。Pete Hodgson 的文章对这些类别及其生命周期作了区分。

在设计时，建议说明默认行为、适用环境、目标对象、配置失效时的回退、日志和清理安排。重要逻辑应覆盖开启、关闭、不同变体以及配置失效时的关键路径；对于组合影响较大的开关，还要检查兼容边界。上线过程中要让扩大比例的节奏与可观察数据相匹配，不把一次小流量成功理解为全量无风险，也不把自动回滚视为完整的事故预防机制。最终，功能开关是一种应用级的运行时决策技术；渐进式交付是利用分阶段暴露、验证和控制变更风险的交付实践；A/B 测试则是通过受控比较来学习方案效果。三者可以协作，各自解决的问题仍然不同。