功能开关（Feature Flag）是现代软件交付里最有效的工具之一：支持灰度发布、A/B 实验、未发布功能门控，以及生产环境的即时熔断开关。但这里有个悖论——加一个开关极其便宜，放着不管却极其昂贵。GeekyAnts 工程团队的分析指出，当团队不为开关维护排期，短期发布开关就会变成永久性的结构复杂度。
加开关只需几分钟：把代码包进条件判断、接上配置中心，还能和新功能放在同一个 PR 里通过评审，部署零阻力。删开关却是完全不同的工程量——要在应用逻辑、分析管道、日志宏和告警定义里找出该 key 的每一处引用，判断哪条执行路径已永久生效并删掉废弃分支，清理覆盖死路径的单元与集成测试，还要确认下游微服务不依赖旧的状态签名。这些工作直接和能带来收入的功能交付抢资源，于是产品经理和工程负责人很少给它排优先级。一个原本只打算活 14 天的发布开关，最后躺了 18 个月。
遗留开关不只是代码不整洁，而是真实的结构性风险。每个二元开关都会让系统的理论执行状态翻倍，一个被 4 个独立开关控制的例程最多有 16 条执行路径，穷举测试几乎不可能，会留下只在罕见生产流量下才触发的静默边界情况。工程师离职、换项目或忘记早期架构决策后，陈旧的开关会让新人不敢动相关模块，催生绕行写法和二次技术债。开关引用还会逐渐泄漏到分析 schema、日志聚合、开关厂商配额和外部 API 契约里，清理拖得越久，最终移除时的爆炸半径越大。
分析强调，不是所有开关都一样，很多团队失败在于用一刀切策略管理本质不同的开关。发布开关典型寿命是几天到几周，用于门控未完成工作或编排金丝雀发布，一旦稳定在 100% 就应立即移除；实验开关寿命等于 A/B 测试周期，用于衡量不同变体的用户行为，实验结束即应移除；运维/熔断开关寿命无限期，用于故障期间关闭重外部依赖，应永久保留并定期复查。在创建时就分类，才能给不同开关设定合理的寿命阈值。
靠人的记忆排期清理注定失败，需要自动化机制识别死开关。一个轻量陈旧度检测脚本的思路是：按类型设定阈值（release 14 天、experiment 45 天、ops 365 天），只把 rollout 为 0 或 100 的开关视为清理候选，若稳定天数超过该类型上限就标记为 STALE，并输出 key、owner 和超期天数。把这类逻辑接进 CI/CD 流水线或每周的 Slack 集成，陈旧开关就会被自动暴露，而不是等到事故复盘时才被发现。
结论是：功能开关是持续交付的关键工具，但没有专门的生命周期策略就必然变成危险的技术债。解决它不需要复杂机器，只需要创建时清晰分类、自动化陈旧度追踪，以及为移除 PR 预留专门的迭代容量。把删除开关当作软件交付的标准步骤，代码库才能保持干净、可维护和有韧性。