驯服桀骜不驯的代码：Kotlin 项目中的 Feature Flags

前言：为什么功能会破坏发布？

每个开发者至少都曾遇到过这样的情况：一个崭新、炫酷的功能已经准备好了，但却不能发布。要么是它没有通过完整的 QA 测试，要么是市场部还没准备好宣传横幅，或者仅仅是因为在周五晚上害怕按下“部署”按钮。这时，我们通常会开始写 if 语句，切换 BuildConfig，或者更糟的是，注释掉代码。

熟悉吗？欢迎来到 功能标志（或功能开关）的世界。这不仅仅是“又一个架构上的东西”。它是你的救生圈，让你可以将代码部署到生产环境，但只对选定的用户启用。在本文中，我们将探讨如何在 Kotlin 项目中实现 功能标志——从简单的解决方案到高级系统。是的，会有很多代码。

什么是 Feature Flag，你为什么需要它？

Feature Flag（又称功能开关）是一个软件开关，允许你在不更改代码和重新部署的情况下启用或禁用功能。想象一下，你可以将新的推荐算法部署到生产环境，但只对 5% 的用户激活它。或者只对公司员工启用，用于内部测试。很酷，对吧？

以下是功能标志不可或缺的几个场景：

• 金丝雀发布：将新功能部署到 1% 的服务器上，监控错误，然后逐步提高百分比。
• A/B 测试：在不复制整个项目的情况下，测试哪个 UI 版本转化率更高。
• 紧急开关：如果新功能开始“吞噬”内存或引发 bug，你只需一键（或一个 API 请求）即可将其关闭。
• 发布与部署分离：代码已部署，但功能“休眠”直到日期 X。

在 Kotlin 中，它被广泛用于后端（Ktor, Spring Boot）和移动应用（Android），由于严格的类型系统和代码整洁性要求，功能标志变得尤为重要。

架构：如何不让标志变成意大利面条式代码

新手最大的错误是在整个项目中到处散布 if (flag.isEnabled()) { ... } else { ... }。这会导致一个月后你无法分辨哪些代码分支是活的，哪些是死的。我们需要的是 功能管理，而不是混乱的开关。

好的架构建立在 依赖反转 原则之上。你的业务代码不应该知道标志值从何而来（来自文件、数据库还是外部服务）。它只是询问：“嘿，FeatureFlagService，new_checkout 功能开启了吗？”

我们来看两种方法：简单方法（适用于小型项目）和高级方法（适用于微服务和 Kubernetes）。

1. 简单方法：配置和枚举

如果你需要快速开始，并且不是在构建每秒处理百万请求的系统，可以使用简单的 enum class 和配置文件（例如，Ktor 的 application.conf 或 Spring 的 application.yml）。

创建一个包含所有功能的枚举：

enum class Feature(val key: String) {    NEW_PAYMENT_FLOW("feature.new-payment-flow"),    DARK_MODE("feature.dark-mode"),    SMART_SEARCH("feature.smart-search")}

现在，一个读取配置的服务：

class FeatureFlagService(private val config: Map<String, Boolean>) {

    fun isEnabled(feature: Feature): Boolean {        return config.getOrDefault(feature.key, false)    }

    // 对于 A/B 测试，可以添加随机化    fun isEnabledForUser(feature: Feature, userId: String): Boolean {        if (!isEnabled(feature)) return false        // 用于分组的简单哈希        val group = userId.hashCode() % 100        return group < 50 // 50% 的用户