小步发布也可以用 Feature Flag

那次上线让我重新理解「小步」

我以前觉得 Feature Flag 是大公司才玩的东西——要上专门的 SDK，要接管理后台，还要做灰度策略，小团队根本没必要。直到有一次，我在一个三人团队里做了一次「小步发布」：把旧的支付接口替换成新接口，灰度 10% 用户，结果新接口在某个第三方回调场景下直接报错。因为流量小，我们 15 分钟内发现问题，关掉开关，零客诉。

那次之后我意识到，Feature Flag 不是「大项目专属」，它是任何需要「先上线再说」的场景的安全网。小团队的小步发布，往往更需要这张网——因为你没有专门的 QA 团队帮你兜底，也没有灰度集群帮你分流，开关是你唯一能抓住的东西。

这篇文章我会从实际案例出发，聊清楚三件事：什么时候该加开关、怎么加才不会变成技术债、以及小团队该怎么把这套东西低成本跑起来。

Feature Flag 到底在解什么问题

先说一个容易混淆的点：Feature Flag 不是环境变量，也不是配置中心。环境变量解决的是「不同环境用不同参数」，配置中心解决的是「运行时改配置不用重启」。Feature Flag 解决的是另一个问题——把代码合入和功能曝光解耦。

Pete Hodgson 在 Martin Fowler 的博客上把 Feature Toggle 分成四类¹：

小步发布主要用的是 Release Toggles 和部分 Ops Toggles。核心思路很简单：代码可以合入主干、可以部署到生产环境，但功能对谁可见、什么时候可见，由开关决定。

这让我想到一个比喻：Feature Flag 就像水管上的阀门。你可以先把水管铺好（代码上线），但不急着开水（功能曝光）。等确认水压正常、接口没问题，再慢慢拧开。

小团队常见的三个场景

场景一：新旧页面替换

我有一个后台管理系统，老版本的用户列表页用了两年，新设计终于做好了。如果直接一刀切替换，风险在于：万一新页面的某个筛选条件和后端接口对不上，整个列表就挂了，所有用户都受影响。

我选择的方案是加一个 Release Toggle，默认走旧页面，内部测试账号走新页面。观察一周没有数据异常，再按 10% → 30% → 100% 逐步放量。整个过程没有新增部署，只改了开关配置。

// ❌ 硬切方案：直接替换路由
router.get('/users', newUserController.list)
 
// ✅ 开关方案：按条件路由
router.get('/users', (req, res) => {
  if (featureFlag.isEnabled('new-user-list', req.user.id)) {
    return newUserController.list(req, res)
  }
  return legacyUserController.list(req, res)
})

这个例子的关键不是代码有多复杂，而是决策点和决策逻辑分离。我没有在路由里直接写 if (req.user.id === 'xxx')，而是把判断逻辑交给 Feature Flag 服务。这样后续想改成按百分比放量、按租户灰度，都不用改代码。

场景二：推荐算法替换

另一个场景是推荐逻辑替换。老算法是基于简单的时间排序，新算法引入了协同过滤。推荐系统的特点是效果很难在测试环境判断——你得看真实用户的点击率和转化率。

这里的开关用法不太一样。我用了 Experiment Toggle 的思路，按 user_id 哈希分桶，确保同一个用户始终看到同一种排序结果（体验一致性）：

// ❌ 按随机数分桶：同一用户每次看到不同结果
const useNewAlgo = Math.random() < 0.1
 
// ✅ 按用户 ID 哈希分桶：体验一致
function shouldUseNewAlgo(userId: string): boolean {
  const hash = crypto.createHash('md5').update(userId).digest('hex')
  return parseInt(hash.slice(0, 8), 16) % 100 < 10 // 10% 灰度
}

Unleash 的最佳实践文档专门提到这一点：渐进式发布时必须保证体验一致性，用哈希算法分配固定分组，而不是随机数²。否则用户刷新一下页面，界面就变了，体验会很差。

场景三：高风险权限策略

有一次我们要改计费逻辑——从「按月扣费」切到「按量扣费」。这种改动不能出错，因为直接影响用户的钱。我加了一个 Ops Toggle，不是用来灰度的，而是用来降级的：上线后如果发现新计费逻辑有异常（比如扣费金额偏差超过 5%），运维可以在 10 秒内切回旧逻辑，不需要重新部署。

// ❌ 没有降级手段：出错只能回滚部署
const bill = await newBillingService.calculate(usage)
await billingRepo.save(bill)
 
// ✅ 有降级开关：异常时秒级切回
async function calculateBill(usage: Usage) {
  if (!featureFlag.isEnabled('usage-based-billing')) {
    return legacyBillingService.calculate(usage)
  }
 
  const newBill = await newBillingService.calculate(usage)
  const legacyBill = await legacyBillingService.calculate(usage)
 
  // 双算对比，偏差过大自动降级
  if (Math.abs(newBill.amount - legacyBill.amount) / legacyBill.amount > 0.05) {
    logger.warn('billing deviation detected, falling back', { newBill, legacyBill })
    await featureFlag.disable('usage-based-billing')
    return legacyBill
  }
 
  return newBill
}

这个「双算对比 + 自动降级」的模式，我在后续的几个高风险改动里反复用到。它的好处是：你不需要人工盯着监控大盘，代码自己会在异常时保护用户。

开关的生命周期：从创建到清理

加开关容易，清理开关难。Statsig 的一份报告提到，过期未清理的 Feature Flag 是工程团队的隐形负担——有团队发现一个数据库逻辑切换的 flag 挂了四年，没人知道它干什么³。

Martin Fowler 的文章里有一句话说得很到位：「Savvy teams view their Feature Toggles as inventory which comes with a carrying cost, and work to keep that inventory as low as possible.」 意思是，成熟的团队把 Feature Flag 当成有持有成本的库存，尽量保持最低量。

我给每个开关建了一个简单的元数据记录：

有了这张表，清理就有了依据。我的经验是：Release Toggle 的生命周期不应该超过两个迭代（通常 2-4 周）。如果两个迭代后功能还没稳定，说明问题不在开关，而在功能本身的设计。

下面是我实际执行的一个清理流程：

这个流程看起来重，但实际执行下来，一个开关从创建到清理也就两周。真正花时间的不是操作，而是「观察指标」和「确认无异常」的等待。

四种开关方案的对比

小团队选开关方案时，常见的选项有四种。我整理了一张对比表：

我的建议是：三人以下的团队，用「数据库 + 简单管理后台」就够了。不需要上第三方服务——多一个外部依赖意味着多一个可能挂的点，而且你的开关数量通常不超过 10 个，自研成本很低。

如果你是 Next.js 项目，一个简单的实现是这样：

// lib/feature-flags.ts
import { db } from '@/lib/db'
 
// ❌ 硬编码在代码里：改开关要重新部署
const FLAGS = {
  'new-user-list': true,
  'usage-based-billing': false,
}
 
// ✅ 查数据库：运行时可控，有审计记录
export async function isEnabled(flagName: string, userId?: string): Promise<boolean> {
  const flag = await db.featureFlag.findUnique({ where: { name: flagName } })
  if (!flag || !flag.enabled) return false
 
  // 支持按用户 ID 灰度
  if (flag.rolloutPercentage < 100 && userId) {
    const hash = simpleHash(userId + flagName)
    return hash % 100 < flag.rolloutPercentage
  }
 
  return flag.enabled
}

回滚不是「关掉开关」那么简单

有开关不等于安全。我踩过一个坑：关掉开关后，用户看到旧页面了，但他在「新页面」上已经填了一半的表单丢了。对用户来说，这比「功能不可用」更糟糕——他觉得数据丢了。

所以回滚策略要提前想清楚几个问题：

我后来的做法是：每次加开关之前，先写一份「回滚检查清单」，把上面五项过一遍。如果某一项答不上来，就不急着上线，先把回滚路径想清楚。

小步发布的检查清单

把前面的内容整理成一份可执行的检查清单。每次小步发布前，我会过一遍：

发布前

• 明确这次发布要验证的假设是什么（不是「上线试试」，而是「验证新接口的错误率是否低于 1%」）
• 确认 Feature Flag 的 owner、purpose、expiresAt 已记录
• 默认状态是关闭（功能不可见），而不是打开
• 回滚路径已经想清楚，上面五项检查都过了
• 灰度比例和放量节奏有明确计划（比如 Day 1: 10%, Day 3: 30%, Day 5: 100%）
• 关键指标有监控（错误率、延迟、转化率，至少三个）
• 团队里至少两个人知道这个开关存在，以及怎么关

发布中

• 灰度第一天，主动看监控，不要等告警
• 放量间隔不要少于 24 小时（除非是内部工具）
• 每次放量后记录日志，方便事后复盘

发布后

• 功能稳定后，及时删除旧代码分支
• 移除 Feature Flag，更新元数据状态为 cleaned
• 如果这个迭代没清理，下个迭代规划里必须包含清理任务

最后一条特别重要。很多开关不是不想清理，是「忘了」。把它写进迭代计划，它才有可能被清理。

Knight Capital 的教训

最后提一个反面案例。2012 年，Knight Capital Group 因为一个 Feature Flag 管理失误，15 分钟内损失了 4.6 亿美元¹。原因是：旧代码的 flag 在新版本中被复用，部署时有一台服务器漏更新了代码，导致旧逻辑被意外激活。

这个故事经常被引用来说明「Feature Flag 管理不善的后果」。但我想强调的是另一面：Knight Capital 之所以用 Feature Flag，正是为了做渐进式发布。工具本身没有错，错在没有给 flag 设过期时间、没有检查所有节点的一致性、没有在发布前验证开关状态。

小团队的容错空间比大机构更小，所以更应该从一开始就把规则定好。一个开关从创建到清理，两周时间足够。

小结

Feature Flag 不是大团队的专利。对小团队来说，它更像是一份保险——平时花不了多少时间维护，但在关键时刻能救你一次。

核心就三句话：

1. 该加就加：用户路径、计费、权限、新算法这些高风险改动，开关成本远低于回滚成本。
2. 有始有终：创建时记录元数据，功能稳定后及时清理，不要让它变成技术债。
3. 回滚先行：加开关之前先想清楚怎么回滚，包括数据、缓存、用户状态和下游依赖。

好的发布策略，不是假设不会出问题，而是假设一定会出问题，然后确保出问题时你能在 5 分钟内止血。

参考资料