Marico's space
最近折腾了持续交付这事，踩了不少坑，今天把功能开关（Feature Flag）这个话题彻底说清楚。
如果你看过我之前的文章，应该知道我是主干开发（Trunk-Based Development）的忠实拥趸——主张把 Pull Request 拆得越小越好。理想情况下，开发者每天往主干合并好几次代码，一切顺滑，生产环境稳如老狗。
但实话实说，当你真的去跟一个后端团队聊这事，尤其是他们正在改造核心系统，十有八九会遇到同一种阻力。
会议室后排总有人举手问：“理论上听着挺好，但我现在正在重构老的结算服务，预计要花四天做深度的架构改造。你真的打算让我把半成品、可能跑不通的代码合并到主干，然后直接推到生产环境，让真实用户在买东西时用到？”
这个质疑完全合理。如果你唯一的"隐藏未完成代码"手段就是抱一个大而长期的功能分支，那主干开发分分钟崩给你看。等着你的就是之前聊过的噩梦：大 Merge、深坑代码审查、代码烂在分支里永远见不到生产环境。
要让持续交付真正跑起来，又不在每天下午搞出灾难性生产事故，关键是把两个被大多数团队混为一谈的概念拆开：部署（Deployment）和发布（Release）。
在传统开发模式下，部署代码和发布功能是同时发生的。你合并那个巨大的功能分支，CI/CD 流水线跑起来，代码推到线上服务器，然后——啪——用户立刻看到新功能了。
这种模式风险极高。一旦出问题，你的选择只有两个：回滚整个部署（里面可能包含其他开发者的无关修复），或者在客服工单堆成山、管理层盯死你的情况下，疯狂推一个热修复。
功能开关（Feature Flag）彻底改变了这个风险格局。
部署是把代码搬到服务器上。你的代码跑在生产环境里，安全地藏在水面下，但对终端用户不可见。这是一个技术动作。
发布是让用户真正用到这个功能。这是一个业务决策，跟部署节奏完全解耦。
通过把新代码包在一个简单的条件判断里，你可以每天安全地向生产环境推送十次未完成的逻辑。代码物理上就在服务器上，但执行路径是休眠的。部署的压力就这么被卸掉了。
咱们先跳过那些过度设计的企业框架，看一个标准后端场景。假设你正在把一个老旧的支付网关升级成新的、更可靠的三方 API。
与其等几周憋一个大 PR 一次性全换掉，不如引入一个开关。最简单的样子是这样的：
public class PaymentProcessor { private final NewPaymentGateway newGateway; private final LegacyPaymentGateway legacyGateway; private final FeatureFlagClient flagClient; public void processPayment(Order order) { try { if (flagClient.isFeatureEnabled("use-new-payment-gateway", order.getUserId())) { newGateway.charge(order); } else { legacyGateway.charge(order); } } catch (Exception e) { // Fallback safety net if (flagClient.isFeatureEnabled("use-new-payment-gateway", order.getUserId())) { logger.warn("New gateway failed, falling back to legacy for user: " + order.getUserId(), e); legacyGateway.charge(order); } else { throw e; } } }
}
注意，我们不只是检查一个全局的布尔开关，而是把 order.getUserId() 传给了开关客户端。这使得运行时可以根据上下文动态评估。
有了这套东西，你可以在新网关代码只完成了 20% 的时候就合并。接口在了，基本结构搭好了，但生产环境里对所有人都是关闭状态。你可以在真实 staging 环境或者隐藏的生产路径上持续测试集成，不需要拿真实用户的一笔交易去冒险。
一个常见的反对声音是："数据库变更怎么办？你不可能用功能开关来屏蔽一次 Schema 迁移。"这确实是很多团队栽跟头的地方。如果你的代码依赖一个还不存在的数据库列，应用直接崩给你看。要解决这个问题，你的数据库策略必须和代码隔离方案同步演进。秘诀就是Expand and Contract（扩展-收缩）模式。
不要在单次破坏性操作中重命名或修改列，而是把变更拆成多个向后兼容的部署：
Expand 阶段：部署一个迁移，添加新列或新表。老代码不知道它的存在，所以一切照旧。
Dual Write 阶段：部署一个功能开关，开始同时往新旧两列写数据，但仍然只从旧列读。这确保新 Schema 能用真实数据填充。
Backfill 阶段：运行一个后台脚本，把历史数据从旧结构迁移到新结构。
Flip the Switch：把功能开关改成从新列读。如果性能出现劣化，立刻把开关拨回去。
Contract 阶段：当你 100% 确定没问题后，删除功能开关、清掉旧代码路径，再部署最后一次迁移删掉旧列。
是的，步骤更多了。但它把一次可怕的数据库迁移变成了一系列无聊到发指、但完全安全的任务。
一旦把部署和发布解耦，你会解锁一些让传统 staging 环境显得过时的部署流程。其中最强大的就是金丝雀发布（Canary Release），也叫渐进式 rollout。
不用一开开关就赌数据库不会在新查询负载下熔掉，你可以配置功能开关系统根据百分比或特定用户属性来评估。对于我们的新支付网关，一个现实的 rollout 计划是这样的：
阶段一：内部测试（QA 梯队）
开关只对内部 QA 团队的 user ID 或者特定白名单的公司 IP 开启。你在真实生产基础设施上跑测试，用真实的数据库连接，但公司外部没人知道这事。
阶段二：金丝雀（1% 流量）
你把恰好 1% 的随机全局流量路由到新网关。坐下来盯着日志控制台看一小时，盯着 500 错误飙升、延迟上涨、数据库连接池异常消耗。如果 1% 的用户遇到 bug，这是个小问题，你很快能捕获，而不是影响所有人的全公司级宕机。
阶段三：逐步放量（10% -> 50%）
如果 24 小时后各项指标干净，就把开关扩到 10%，再花两天扩到 50%。这种渐进式增长帮助你观察系统在真实负载下的表现。
阶段四：全量发布（100%）
功能稳定了，指标完美了，老旧支付网关可以正式下线了。
如果在 10% 阶段出现了一个边界 case bug，不用慌。不用触发整个服务容器回滚（可能需要 15 分钟编译部署），只需要登录功能开关控制台，把开关拨回 0%，然后在正常工作节奏下慢慢修。
如果你跟任何在混乱快节奏项目里用过功能开关的后端工程师聊过，他们都会警告你同一件事：技术债务。把功能开关当魔法棒到处撒实在太容易了，直到你的代码库看起来像一碗纠缠的面条。
如果一个开关在功能已经全量上线后还赖在代码里超过六个月，它就不再是持续交付的工具，而是架构负担。它让代码更难读，单元测试更复杂（因为要 mock 各种开关状态），死代码路径无限挂起。
要防止系统变成不可维护的迷宫，你需要在开关生命周期上建立严格的工程纪律。
每次创建功能开关时，应该立刻在 backlog 里创建对应的移除 ticket。一个新功能的 Definition of Done 不应该是"它在生产跑通了"，而应该是"它在生产跑通了，老代码删掉了，开关条件判断从代码库里彻底剥离了"。
每个开关必须有明确的负责人——具体某个开发者或某个产品团队。如果一个开关四周末动过，自动化系统或 tech lead 应该触发预警去审视状态。
发布开关的存活期不应超过一个开发冲刺周期，最多两个。如果一个开关在 100% 开启状态下稳定跑了几天没投诉，就该安排一个快速清理 PR 了。别让它们变成永久配置项。
起步阶段不需要从零造一个庞大复杂的内部配置平台。对于小团队，一个简单的中心化数据库表或者 Redis 支撑的配置文件（动态热加载）就足够让你入门。
当团队扩张，需要高级定向规则、百分比 rollout 和审计日志时，看专门的工具就很有价值了，比如 LaunchDarkly、Flagsmith，或者开源方案 Unleash。
关键的架构要求是：开关评估必须飞快。不能每次调用函数时在关键后端路径上引入一个阻塞 HTTP 请求；它需要在本地内存中解析，通过后台异步同步的缓存开关状态来实现。
转型到每天往生产环境推送十次的workflow，不是工程团队的炫技——而是为了减压。它改变整个开发团队的文化。生产部署不再是高压力、深夜作战、人人开着笔记本待命的活动。它们变成无聊、常规、完全不惊动人的日常，在后台持续发生，你该喝咖啡喝咖啡，该做下一个任务做下一个任务。
功能开关就是让这一切成为可能的缺失环节。它们给你安全网，让你保持 PR 很小、主干常绿、交付流水线持续向前，同时永远不打破用户体验。