一个前端项目里有六十多个功能开关，分布在配置中心、构建变量和代码常量三处。上线半年后，运营想知道"某个开关现在是什么状态"，答案需要查三个地方、再问一个人，最后发现那个开关早就不起作用了——因为对应的代码分支在某个版本里被改成了默认路径。
功能开关的价值是"不改代码就能改变行为"，代价是每一个开关都是一条永久存在的分支。开关数量增长的速度通常远快于清理速度，于是开关系统从"降低风险"变成了"增加不确定性"。
1. 开关的四种类型
| 类型 | 生命周期 | 谁管 |
|---|---|---|
| 发布开关（上线用） | 数天到数周 | 开发 |
| 实验开关（A/B） | 数周 | 产品 + 数据 |
| 运营开关（活动、入口） | 数月 | 运营 |
| 权限/降级开关 | 长期 | 运维 |
类型混淆的后果很具体：把发布开关当成运营开关，它会因为"运营可能还要用"而永远不删；把运营开关当成发布开关，它会在一次发版后被顺手删掉，活动当天入口消失。两类错误都源于"开关"这个词掩盖了四种不同的东西。
四类混在一个系统里是常态，但它们的管理规则完全不同：发布开关必须有到期时间，实验开关必须有结论，运营开关必须有归属，降级开关必须有触发条件。
2. 开关的三种存放位置
| 位置 | 生效时机 | 风险 |
|---|---|---|
| 构建时注入（环境变量） | 需要重新构建 | 改一次要发版 |
| 运行时读取（配置接口） | 刷新即生效 | 首屏可能闪烁 |
| 代码常量 | 需要发版 | 失去开关意义 |
第一种最常被误用：团队以为"用了环境变量就是开关"，但改它需要重新构建部署，等于没有获得开关的核心收益。
存放位置还会影响排查：同一个开关在三个位置都有值时，最终取哪个由代码里的读取顺序决定，而这个顺序通常没人记得。可行做法是只允许一处生效，其余位置只做兜底默认。
// 优先级显式写清，并在启动时打印来源
const value = runtimeFlags[name] ?? buildFlags[name] ?? DEFAULTS[name] ?? false;
const source = name in runtimeFlags ? 'runtime' : name in buildFlags ? 'build' : 'default';
// 打印 source 让"为什么这个开关是这个值"可回答
第二种才是真正的开关，代价是要处理"加载中"与"加载失败"两种状态。
// 运行期开关：必须处理三种状态，否则会出现闪烁或错误默认
const flags = await loadFlags().catch(() => ({})); // 失败时给空对象
const enabled = flags[name] ?? DEFAULT[name] ?? false;
// 首屏渲染前拿到开关值，避免"先渲染旧版再切新版"的闪烁
3. 分支的爆炸成本
| 组合来源 | 组合数 |
|---|---|
| 单个开关 | 2 |
| 两个独立开关 | 4 |
| 五个独立开关 | 32 |
| 三个开关且互相嵌套 | 分支路径远超 8 |
一个可用的检查方式是给每个开关标上互斥关系，让工具在初始化时拒绝非法组合：
// 开关关系声明：初始化时校验，避免运行期出现非法组合
flags:
new_checkout: { requires: [], conflicts_with: [] }
new_payment: { requires: [new_checkout], conflicts_with: [] } // 依赖关系
legacy_ui: { requires: [], conflicts_with: [new_checkout] } // 互斥
第三行是纸面上的组合数，实际代码里还有"开关 A 只在开关 B 为真时才有意义"这类约束，它们不会自动被排除，而是变成运行时才发现的非法状态。
// 典型的分支爆炸：三层嵌套 + 两个互斥条件
if (flagA) {
if (flagB) { renderNew() } else { renderOld() }
} else {
if (flagC) { renderFallback() } else { renderLegacy() }
}
// 实际被验证过的组合通常只有 2–3 条，其余都是"没人走过"的路径
4. 清理机制比开关本身重要
| 机制 | 效果 |
|---|---|
| 到期时间 | 强制回收 |
| 归属人 | 有人负责 |
| 使用统计 | 知道哪些没被用过 |
| 定期清单 | 避免遗忘 |
第一项最有效：创建开关时就写下"预期删除时间"。没有这一步，开关会以"也许以后还用得上"的理由长期存在。
清理的节奏也很重要：每个发布周期留出固定的"开关清理时间"。没有这个时间预算，清理永远是"下次再说"，而下次永远不来。
第三项需要埋点：上报每个开关的取值分布，如果一个开关长期只取一个值，它已经是常量了，应当删除。
// 开关取值上报：长期单值的开关就是待清理对象
reportFlag(name, enabled);
// 一周后统计：enabled 恒为 true 的开关 → 可以直接内联为常量
开关系统还需要一个"入口"约束：能加开关的人应当有限。如果任何开发者都能随手加一个永久开关，那么清理速度永远追不上增长速度。常见做法是把开关的创建纳入评审，与"新增一张配置表"同等级别。
5. 删开关的正确顺序
| 步骤 | 操作 |
|---|---|
| 1 确认取值 | 统计近 30 天分布 |
| 2 固化分支 | 保留主路径，删另一条 |
| 3 观察 | 一个发布周期 |
| 4 删开关定义 | 从配置中心移除 |
| 5 删埋点 | 清理统计代码 |
第二项与第四项的顺序不能反：先改代码固化行为，再删开关定义。反过来会让线上读取一个不存在的开关，落到默认值上，行为可能和预期不同。
开关与缓存的交互也常出问题：前端读到的开关值如果被 CDN 或浏览器缓存，那么"改了开关但用户看到的还是旧的"就会发生。开关接口必须禁止缓存，或在 URL 上带版本号。
// 开关接口不缓存：一份缓存保住一天，开关就等于失效一天
location /api/flags {
add_header Cache-Control "no-store, must-revalidate";
# 或按版本号取：/api/flags?v=<build_id>
}
6. 排错：五种"开关不生效"
| 现象 | 成因 | 处理方向 |
|---|---|---|
| 改了配置没变化 | 读的是构建期变量 | 改运行时读取 |
| 部分用户生效 | 缓存未刷新或 CDN 缓存 | 检查缓存键与 TTL |
| 首屏闪烁 | 开关异步加载 | 首屏前取到值 |
| 开关删了但行为没变 | 代码里还有硬编码 | 搜索残留分支 |
| 两个环境行为不同 | 配置不同步 | 开关值纳入配置对比 |
排查这类问题有个直接手段：把开关的取值全打印一次，与代码里的分支对照。
// 一次性导出所有开关的当前取值，与代码搜索对照
curl -s "$FLAG_API/all" | jq -r 'to_entries[] | "\(.key)=\(.value)"' | sort > flags.txt
grep -rho "flag("[a-z_]*")" src/ | sort -u > used.txt
comm -13 flags.txt used.txt // 代码在用但配置里没有的开关
第四项很常见：删掉开关定义后，代码里 if (flag) 的 flag 变成 undefined，走 else 分支——看起来"行为没变"，其实是碰巧走了同一条路。
7. 边界：什么情况不必用开关
| 场景 | 为什么 | 做法 |
|---|---|---|
| 纯内部工具 | 无风险 | 直接发布 |
| 一次性的界面文案调整 | 可回滚 | 直接发布 |
| 已有灰度能力（按用户比例） | 功能重复 | 用灰度而不加开关 |
| 分支无法回滚（涉及数据结构） | 开关无效 | 用兼容性设计 |
判断口径一句话：这个开关有没有一个明确的删除时间。答不出，就不要加；答得出，就把它写进创建记录。
8. 自测
- 开关的四种类型分别由谁管、生命周期多长？为什么"发布开关必须有到期时间"？
- 构建时注入与运行时读取的差别在哪里？为什么前者"等于没有开关"？
- 五个独立开关的组合数是多少？为什么实际被验证过的组合远少于这个数？
- 清理机制的四个手段中，哪两个最有效？"长期单值的开关"意味着什么？
- 删开关的五步中，为什么"固化分支"必须在"删定义"之前？
- "删了开关但行为没变"为什么可能是假象？