Feature Flag究竟是什么？
先讲个故事。我刚带团队时，有一次上线一个支付模块的重构，代码review了三轮，测试环境跑了两天，预发一切正常。结果全量发布后五分钟，线上订单大量报错——某个第三方接口的响应格式在新版本里改了，但老版本的兜底逻辑没覆盖到。回滚花了二十分钟，损失了好几个九的可用性。
事后复盘时我就在想：要是能只让一小批用户先跑新逻辑，哪怕出问题也只有千分之一的人受影响，那该多好？这就是Feature Flag最朴素的动机——
把「发布」和「上线」彻底拆开。
说白了，Feature Flag就是一个运行时的开关。代码里写一个if条件，根据某个标识决定走哪条路。这个标识可以来自配置文件、数据库、远程服务，甚至可以是用户ID的哈希值。
为什么我们需要它？
我以前也觉得，不就是个if else嘛，至于搞成个体系？后来踩过几个坑才明白——它解决的是软件交付中最根本的矛盾：开发速度 vs. 系统稳定性。
你想想看，传统做法里，一个新功能必须全部开发完、测试完、审批完，才能通过一次大版本发布出去。这个周期少则几天，多则几周。遇到紧急修复？不好意思，你得走完整条发布流水线。
Feature Flag把这一切打破了。我个人的经验是：
- 主干开发成为可能：所有开发都在master分支上做，用Flag把未完成的功能隐藏起来。再也不用开长生命周期的特性分支了。
- 快速回滚变成按秒计：出问题？关闭Flag就行，不用回滚代码包。我曾经靠这个在一次大促前五分钟救回了整个会场。
- 灰度发布是标配：先开放给内部员工，再开放给1%的外部用户，接着10%、50%……每一步观察指标，有问题立马切回来。
常见应用场景，我挑几个重点说
灰度发布
这是最常见的用法。拿我们之前做的新推荐算法举例：
# 伪代码
if feature_flag.is_enabled("new_recommendation", user_id):
result = new_recommendation_engine(user_id)
else:
result = old_recommendation_engine(user_id)
我们首先只放给5%的用户，观察点击率。如果指标正向，逐步扩大到10%、30%、最后100%。如果点击率掉头，秒级关闭Flag——整个过程不需要重新部署一行代码。
A/B测试
很多团队把A/B测试和Feature Flag混为一谈，其实不完全一样。Feature Flag是基础设施，A/B测试是建在上面的实验框架。但底层逻辑相通：
- 用Flag把用户分成实验组和对照组
- 跟踪两组的关键指标差异
- 用统计方法判断哪个版本更优
我记得有一次测试支付页面的"免密支付"入口位置，两边数据跑了三天，实验组转化率高了8%。结论很明确，秒级全量放开。
权限控制
这个场景看似简单，但踩坑的人不少。我曾经见过一个团队用Flag做付费功能的白名单控制，结果Flag的值缓存了十分钟，用户付了钱但等十分钟才能用——差点被投诉。
实验性功能 & 内部员工预览
大团队里经常有这种情况：新功能还不稳定，想先让QA或产品经理上手体验。给他们的账号打一个"internal"标签，然后开启对应的Flag。这样他们能在生产环境看到新功能，普通用户不受影响。
Feature Flag的两种主流模式
| 模式 | 特点 | 我推荐的使用场景 |
|---|---|---|
| 发布开关 | 短期存在的Flag，功能稳定后立刻移除 | 灰度发布、金丝雀发布 |
| 运营开关 | 长期存在，用于控制业务逻辑（比如节日皮肤、促销入口） | B端功能权限、动态配置 |
这里有个重要的点：发布开关用过一定要删。我见过某公司的代码库里躺着上百个两年前上线的Flag，没人敢动——因为不确定哪个模块依赖它。最后不得不用代码扫描工具一个一个排查。说白了，欠下的技术债总要还。
一张图看懂Feature Flag的核心价值
最后说点实战体会
Feature Flag不是银弹。我记得刚开始推广时，团队里有人把Flag嵌套了五层，代码可读性极差。还有同学把Flag的key写死在字符串里，全局搜都搜不到。后来我们规范了命名：ff_模块名_功能描述_日期，配合自动化清理脚本，才把烂摊子收拾干净。
嗯，这一章我们就先聊清楚概念和价值。有了这个基础，后面再深入怎么设计Flag体系、怎么自动化测试、怎么管好回归。你想想看，如果连为什么要用Flag都没想明白，后面那些技术细节迟早会走偏——这是我在十几年的工程生涯里反复验证过的。