下午 2:00，新版本正式上线。到了 2:05，由于新 Beta 功能中存在一个慢数据库查询，CPU 使用率飙升至 95%。如果你依赖环境变量，解决这个问题需要修改配置文件。你必须提交更改、推送到仓库，然后等待 10 分钟的 CI/CD 流水线来重新构建和部署容器。在这十分钟里，你的用户会不断遇到错误。而如果你使用功能开关（feature flag），只需在界面上拨动一下开关，或运行一条简单的命令行指令，该功能就会瞬间关闭。
环境变量 vs. 功能开关：界限划在哪里
环境变量（env vars）非常适合静态配置。它们定义了应用程序的运行环境——例如数据库连接字符串、第三方 API 密钥和端口号。这些值极少发生变化。即使发生变化，重新启动应用或重新部署也是可以接受的。
功能开关解决的是另一个问题。它们用于管理运行时行为。当你希望在不重新构建代码或重启服务器的情况下改变应用的运行方式时，就可以使用功能开关。
环境变量无能为力的转折点在于“精准定向”（targeting）。如果你只想对加拿大 5% 的用户展示新的支付网关，环境变量根本帮不上忙，因为它们会全局应用于整个进程。而功能开关可以在运行时评估上下文信息（如用户 ID、地理位置或邮箱域名），从而做出动态决策。
简而言之，构建时的配置使用环境变量；而需要在不重新部署代码的情况下动态改变运行时行为时，请使用功能开关。
自研方案：简单、便宜，但局限明显
许多工程团队最初都会选择自己构建开关系统。在 Redis 中搭建一个基础的键值存储，或者在 PostgreSQL 数据库中添加一个 features 表，都是非常容易上手的。
例如，我们来看一个使用 Redis 的基础 Node.js 实现：
// 自研开关检查的示例代码
async function isFeatureEnabled(userId, featureName) {
const flagValue = await redis.get(`flag:${featureName}`);
if (flagValue === 'true') return true;
if (flagValue === 'false') return false;
// 简单的按比例分流逻辑（例如，flagValue = "20"）
const hash = getSimpleHash(userId); // 返回一个介于 0 到 99 之间的示例数字
const rolloutPercentage = parseInt(flagValue, 10);
return hash < rolloutPercentage;
}
在这个示例中，如果 Redis 键 flag:new-checkout 被设置为 20，那么只有 20% 的用户能看到新的结账页面。这种方式在项目初期运行得很好，没有任何外部依赖，运行成本几乎为零。
然而，维护负担会迅速增加。当产品经理希望只针对“在上周二之前注册且使用企业邮箱域名”的用户进行定向展示时，该怎么办？在应用代码中编写自定义的定向规则会变得一团糟。你还必须构建一个管理后台界面，以便非技术人员能够安全地切换开关。如果没有审计日志，你很难查出是谁在凌晨 3:00 关闭了某个关键开关。
自研开关系统非常适合简单的布尔值切换，但当你需要复杂的定向规则或审计日志时，它很快就会分散团队的精力。
LaunchDarkly：强大的定向功能与企业级规模
LaunchDarkly 是市场上的领头羊。它采用基于服务器发送事件（SSE）的实时流式架构。当你在 LaunchDarkly 控制面板中更新某个开关时，更改会在几毫秒内同步到你的服务器和客户端。
它的定向引擎非常强大。你可以根据传递给 SDK 的任何自定义属性（如订阅层级、设备类型或历史使用情况）来定位用户。它还内置了实验工具，用于运行 A/B 测试和多变量发布。
相应的代价是成本。LaunchDarkly 是一款高端产品，其定价根据月活跃用户数（MAU）进行阶梯式收费。对于高流量的消费级应用，这种定价模式可能会变得非常昂贵。此外，由于你的代码库会与 LaunchDarkly 的专用 SDK 深度绑定，还存在供应商锁定的风险。
LaunchDarkly 非常适合需要复杂用户定向、实时更新和高级实验功能的大型工程团队。
Flagsmith：开源灵活性与自托管支持
Flagsmith 提供了另一种思路。它是一个开源的功能开关平台，你既可以使用其托管云服务，也可以在自己的基础设施上进行自托管。你可以使用 Docker、Kubernetes 进行部署，或者直接在 AWS、GCP 或 Azure 上运行。
这种部署灵活性对于有严格合规要求的组织来说非常宝贵。如果你无法将用户数据发送到第三方服务器，完全可以在私有网络中运行 Flagsmith。
Flagsmith 提供了简单直观的 API。虽然它的功能集比 LaunchDarkly 稍微精简一些，但它能很好地处理标准定向、多变量开关和环境管理。它的定价模式更具可预测性，根据 API 调用次数或席位数量收费，而不是严格追踪每一个月活跃用户。
如果你需要本地化部署、开源透明度或更具可预测性的定价模式，Flagsmith 是一个极佳的选择。
如何选择：权衡对比
在这些选项之间做出选择，需要平衡运维开销与自主控制权。
考虑一下每种方案如何处理延迟。如果你的应用每次检查开关时都要向外部数据库或 API 发起网络请求，页面加载时间就会受到影响。为了避免这种情况，LaunchDarkly 和 Flagsmith 都采用了本地评估机制。SDK 会在应用启动时下载开关规则集并将其缓存在内存中。当用户请求页面时，SDK 会在微秒内完成本地评估。
而自研的数据库驱动系统则需要你实现自己的缓存层（如 Redis），以避免频繁的开关查询对主数据库造成冲击。
如果你只需要几个基础的开关用于内部测试，那么在内部构建一个简单的系统是合理的。但如果你有一个不断壮大的产品团队，需要无需工程师干预即可进行复杂的灰度发布，那么一款专用的工具就必不可少。
简而言之：基础内部测试选择自研方案；需要自托管控制权选择 Flagsmith；需要托管型、大规模定向功能则选择 LaunchDarkly。
在 StackMatch 上对比功能管理工具
选择合适的功能开关工具取决于你的技术栈、预算和合规需求。你可以在 StackMatch 上探索更多选择，我们提供了精选的工具列表、直观的对比表格，以及针对易用性、价格透明度和集成便捷性进行评分的编辑评测。
常见问题
我应该在什么时候从环境变量迁移到功能开关服务？
当你需要在运行时改变应用行为而不想触发新的 CI/CD 部署流水线时，或者当你需要根据自定义属性精准定向特定的用户群体，而不是全局应用更改时，你就应该进行迁移。
使用第三方功能开关工具会给我的应用带来延迟吗？
大多数现代功能开关 SDK 都通过本地评估机制来降低延迟。开关规则会缓存在服务器的内存中，并通过流式连接进行异步更新，从而使开关检查的延迟几乎为零。
对于小团队来说，Flagsmith 是 LaunchDarkly 的可行替代方案吗？
是的，Flagsmith 是一个非常可行的替代方案——特别是对于那些更倾向于开源软件、因合规原因需要自托管，或者希望采用更具可预测性（按 API 调用次数而非月活跃用户数收费）的定价结构的团队。
自建功能开关系统有哪些隐藏成本？
虽然初始构建成本很低，但自研系统的隐藏成本在于持续的维护。你必须为非技术团队成员构建并保障一个管理后台界面的安全，实现审计日志，并确保开关分发基础设施的高可用性。