feature flag 越加越多没人敢删：一份可执行的功能开关退役验收清单

结论先行：feature flag 不是"代码里的布尔值"，它是"一条没被任何人正式退役的执行路径"。我们团队 18 个月里 feature flag 从 47 个涨到 312 个，其中 194 个（62.2%）实际上已经没有任何流量走旧分支，但代码里 312 个 if 分支都还在——每一次发布、每一次 code review、每一次新人 onboarding，都要为这 194 个"僵尸 flag"付一次认知税。这篇文章给一份可以直接抄进退役流程的验收清单，并附上我踩过的 4 个坑。

一、现象与背景：flag 数量是"只增不减"的单调函数

先看一组真实数字。我所在团队一个中型业务中台（Java 17 + Spring Boot 3.2，12 个微服务），feature flag 治理数据：

• 存量：312 个 flag，分布在 6 个仓库；
• 年龄分布：>12 个月的 141 个（45.2%），>18 个月的 58 个（18.6%），其中 58 个的创建人已经离职；
• 流量分布：拉了 30 天日志，194 个 flag 的"旧分支命中率"为 0（即 100% 走新路径），26 个 flag 命中率 <1%；
• 维护成本：一次常规发布，code review 里平均有 3.2 处 diff 涉及 flag 分支（新增 / 改条件 / 顺手删一个），reviewer 需要额外花约 8 分钟/次判断"这个 flag 还能不能动"。

更扎心的是：没有任何一个 flag 有 owner、有到期时间、有"删除它的验收标准"。创建 flag 的成本几乎为零（加一行配置 + 一个 if），删除 flag 的成本却很高（要确认所有依赖方都迁移完、要跑一轮回归、要说服自己"删了不会出事"）——创建和退役的成本严重不对称，所以 flag 永远在涨，永远不会被删。

我把这个现象叫"flag 的静默负债"：它不像技术债那样能写在 JIRA 里，它藏在 6 个仓库、312 个 if 分支里，每个人都知道"该清理了"，但没有人为"什么时候能删"负责。

二、原理与根因：为什么 flag 会只增不减

三个机制叠加，理解了就能设计对策：

1. 成本不对称。 创建 flag 是 5 分钟的事，删除 flag 要跑一轮全量回归 + 说服 3 个相关方——理性人永远选择创建。这在经济学上叫"非对称交易成本"，工程上唯一的解法是把删除的成本降到和创建同量级，否则靠自觉永远删不掉。

2. 所有权漂移。 flag 创建人 A 在 2025 年 3 月建了一个 flag 控制"新结算逻辑"，2025 年 9 月 A 离职，flag 留在代码里。B 接手时不知道这个 flag 为什么存在，C 接手时连 B 都不认识了——flag 的所有权随着人员流动而漂移，最终变成"公共无主财产"，没人敢动。

3. flag 不是开关，是执行路径。 这是最容易被误解的一点。if (flag) { newPath() } else { oldPath() } 看起来是"开关"，实际上是两条独立的业务执行路径：它们可能走不同的 DB 表、不同的缓存 key、不同的第三方接口、不同的埋点。删 flag = 删一条执行路径 = 一次隐性重构，而不是一次"清理死代码"。这决定了 flag 退役必须按"发布"的规格来验收，不能按"删死代码"的规格来走。

所以根因一句话：flag 退役的阻力不是"没人想删"，而是"没人能证明删了不会出事"——验收标准缺失，风险无法被证伪，于是没人敢签字。

三、具体做法：把 flag 退役固化成一条"退役流水线"

我在团队推了一条 flag 退役流水线，核心是给每个 flag 补上三个缺失字段，并强制走"观察期 → 灰度删除 → 全量删除"三步：

步骤 0：给每个 flag 补齐元数据（一次性盘点）

先跑一个脚本，把 6 个仓库里的 flag 全部捞出来（我们用 @ConditionalOnProperty + 配置中心 key 两种写法混用，脚本用 ripgrep 扫两种 pattern）：

# 扫 @ConditionalOnProperty 注解里的 flag key
rg -n '@ConditionalOnProperty\(' --type java -o -r '$0' | awk -F"=" '{print $2}' | sort -u

# 扫配置中心 key（我们用的是 Apollo，key 格式 feature.xxx.yyy）
rg -n 'feature\.[a-z0-9_.]+' --type java -o | awk '{print $2}' | sort -u > flag_inventory_raw.txt

# 拉 30 天日志里的 flag 命中分布（我们埋了 flag_key 维度日志）
curl -s "https://apollo.internal/config/flags?window=30d" | jq -r '.[] | select(.hits_old > 0) | [.key, .hits_old, .hits_new] | @tsv'

盘点结果落成一张表（我们放在 Confluence，列固定 6 列）：

flag_key              | owner  | 到期日  | 旧分支30天命中 | 删除条件(可断言)  | 状态
feature.settle.v2     | 已离职 | -      | 0              | 新路径全量≥30天    | 待退役
feature.pay.channel   | B      | 2026-08| 1240           | 渠道方书面确认     | 保留
...

关键判据：旧分支30天命中 == 0 且 到期日已过 的 flag，自动进入"待退役"池——用数据说话，不用"我记得这个 flag 没人用了"说话。

步骤 1：观察期（≥14 天，不是 ≥1 天）

把 flag 的旧分支从"可执行"改为"可观测但不可触发"：

// 改造前
if (flagService.isEnabled("feature.settle.v2")) {
    return newSettleService.calc(order);
} else {
    return oldSettleService.calc(order);
}

// 改造后（观察期）
if (flagService.isEnabled("feature.settle.v2")) {
    return newSettleService.calc(order);
} else {
    // 旧分支保留代码，但加一层硬断言：任何走到这里的请求直接 500 + 告警
    log.error("DEAD_BRANCH_HIT flag=feature.settle.v2 traceId={}", MDC.get("traceId"));
    throw new IllegalStateException("flag old-branch hit during observation window");
}

观察期 14 天，判据：

• 旧分支告警数 == 0（一次都不能有，有 1 次 = 观察期作废，回到步骤 0 重新评估）；
• 新路径 P99 ≤ 基线 × 1.1（防止删旧分支后 GC 行为变化影响新路径）；
• 相关埋点 / 报表无异常（旧分支如果埋了点，报表上对应指标归零是正常的，要提前知会数据团队）。

步骤 2：灰度删除（先删 1 个仓库的引用，跑一轮回归）

把 flag 从 6 个仓库里按依赖顺序逐个删掉：先删最下游（只读 flag 不写 flag 的服务），最后删 flag 的定义处。每个仓库删完跑一轮全量回归（我们 CI 里回归套件 47 分钟，不能省）。

删除顺序有讲究：如果服务 A 读 flag 决定调不调服务 B，服务 B 也读同一个 flag 决定走哪条逻辑——必须先删 B 再删 A，否则 A 删完后还在调 B 的新接口，但 B 已经删了新接口 = 线上事故。我画了一张 flag 依赖 DAG（用 rg 扫 flag key 的 import 关系自动生成），删除顺序 = DAG 的逆拓扑序。

步骤 3：全量删除 + 验收签字

最后删 flag 的定义（配置中心 key + 代码常量），跑一轮全量回归 + 一次预发环境的全链路冒烟（3 个核心场景，约 12 分钟）。验收签字条件：

[ ] 旧分支观察期 ≥14 天，告警数 == 0
[ ] 新路径 P99 ≤ 基线 × 1.1（观察期内 P99 数据截图存档）
[ ] 所有 6 个仓库的 flag 引用已删除（rg 全仓库搜索 flag_key，结果 == 0）
[ ] 配置中心 key 已删除
[ ] 全量回归通过（47 分钟套件，截图存档）
[ ] 数据团队确认相关埋点已下线或归档
[ ] owner 签字（owner 离职的，由直属上级代签，注明原因）

四、踩过的坑（4 个，按翻车程度排序）

1. 观察期 1 天就删，结果第 15 天旧分支被触发。 我们第一次退役一个 flag，观察期只给了 1 天（"反正 30 天命中都是 0，应该没问题"）。结果第 15 天一个季度对账任务（每 45 天跑一次，走旧分支）触发了旧代码，数据写进了已下线的旧表，对账结果错了 3 天才被发现。教训：观察期必须覆盖"最长周期任务"的完整周期——如果旧分支被季度任务引用，观察期必须 ≥45 天，不能用 14 天通用判据。盘点阶段就要问一句"这个 flag 的旧分支有没有被定时任务 / 批处理引用"。

2. flag 的旧分支里藏了一个"只有旧分支才写的埋点"。 删 flag 后，数据团队发现一张报表的数据源断了——那个埋点只在旧分支里打，新分支里根本没打。教训：删 flag 前必须确认旧分支里有没有独立的副作用（埋点、写日志、调第三方、写缓存），这些副作用不会出现在代码 diff 里，只有逐行读旧分支才能发现。我把这条加进了验收清单第 6 项。

3. 两个服务读同一个 flag，删除顺序搞反了。 服务 A（上游）删了 flag 后还在调服务 B 的新接口，但服务 B 还没删、还在走旧接口——两边对不上，线上报错 22 分钟。教训：flag 跨服务引用时必须画依赖 DAG，按逆拓扑序删。这次我们靠告警发现的，但如果是低频调用，可能 3 天才发现。

4. owner 离职，没人敢签字。 58 个 flag 的 owner 已离职，我们卡在"谁签字"上停了 3 周。最后定的规则：owner 离职的，由直属上级代签，但代签前必须跑完整观察期 + 全量回归——签字权可以转移，风险不能转移。这条规则写进流程后，退役速度从 3 周/个 提到 5 天/个。

五、结论与可复用清单

一句话总结：feature flag 的退役阻力不是"没人想删"，而是"没人能证明删了不会出事"——解法不是靠自觉，而是把退役标准量化成可断言的判据，让"敢删"变成"流程说能删"。

可直接抄的清单：

[ ] 每个 flag 有 owner 吗？owner 离职了吗？（离职 → 直属上级代签）
[ ] 每个 flag 有到期日吗？（到期日已过 + 旧分支30天命中==0 → 自动进待退役池）
[ ] 旧分支有没有被定时任务 / 批处理引用？（有 → 观察期 ≥ 最长任务周期）
[ ] 旧分支里有没有独立的副作用？（埋点 / 日志 / 第三方调用 / 缓存写入）
[ ] flag 跨服务引用了吗？（有 → 画依赖 DAG，按逆拓扑序删）
[ ] 观察期 ≥14 天（或 ≥ 最长任务周期），告警数 == 0？
[ ] 全量回归通过？（不能省，哪怕"只是删代码"）
[ ] 配置中心 key 已删除？rg 全仓库搜索 flag_key 结果 == 0？
[ ] 数据团队确认相关埋点已下线？

最后补一个反直觉的提醒：删 flag 的回归成本（47 分钟 + 14 天观察期）远高于留 flag 的成本（每次发布多 8 分钟 review）——但"每次发布多 8 分钟"是复利成本，一年 50 次发布就是 660 分钟；而"删 flag"是一次性成本。flag 不删，认知税按发布次数复利累积；删了，认知税一次性归零。这就是为什么 flag 退役必须流程化、不能靠自觉——靠自觉永远算不过这笔账。

核心一句话：创建 flag 是 5 分钟的事，退役 flag 是 14 天 + 47 分钟的事——把退役成本降下来，flag 才能从"负债"变回"工具"。