特性开关与渐进交付：从 Kill Switch 到开关治理

没有开关的世界：
□ 功能上线 = 发版，风险与代码变更绑定
□ 出问题 = 回滚发版（慢、可能丢数据、可能影响其他功能）
□ 新功能要等「发布窗口」，无法随时验证
□ 多个功能抢同一次发版，互相阻塞

有开关的世界：
□ 部署（Deploy）：把代码放到生产，功能默认关闭
□ 发布（Release）：打开开关，让用户可见
□ 回滚 = 关开关（秒级，不影响其他功能、不动数据）
□ 持续部署成为可能：主干随时可发，功能按需放量

开关的四条价值线：
1. 降风险：小流量验证、快速回退
2. 提速度：代码合并即部署，不再等「发布列车」
3. 解耦合：功能、团队、发布节奏互相独立
4. 可运维：Kill Switch 在故障时秒级止损

关键区别在「生命周期」：
□ Release 开关是「临时的」——功能全量后必须删除
□ Ops 开关是「长期的」——是运维能力的组成部分
□ Experiment 开关随实验结束而退役
□ Permission 开关是「产品能力」——长期存在且要有管理界面

混用的代价：
□ 把 Release 开关当 Ops 用 → 永远删不掉，成为僵尸开关
□ 把 Permission 当 Release 用 → 白名单逻辑散落各处
□ 不为开关分类 → 治理时无从下手（该删的没删、该留的被删）

求值模型（Evaluation）：
□ 本地求值：SDK 在进程内根据本地缓存的规则计算
  · 优点：零网络、微秒级、不受配置服务抖动影响
  · 缺点：规则变更需下发，有传播延迟
□ 远程求值：每次请求配置服务（不推荐用于核心路径）
  · 优点：规则实时生效
  · 缺点：网络依赖、延迟、单点

主流做法：本地求值 + 配置下发
□ 启动时拉取全量规则，缓存在内存
□ 配置变更通过推送（SSE/长连接）或定时轮询更新
□ 拉取失败 → 用本地最后一次配置（绝不阻塞启动）

配置分发的一致性设计：
□ 版本号：每条配置带 version，客户端上报版本便于分析
□ 兜底默认值：求值失败时返回「安全默认」（通常是关闭）
□ 分阶段下发：先小比例实例，验证无误再全量
□ 回退：配置服务故障 → 用本地缓存，不阻塞业务

求值结果要能解释：
□ 为什么这个用户命中了这个开关？（记录命中的规则与版本）
□ 排障时能回答「开关为什么是这个值」

// 本地求值：无网络依赖，微秒级，失败回退安全默认
func (e *Evaluator) Bool(flag string, ctx EvalContext, def bool) bool {
    cfg, ok := e.cache.Get(flag)
    if !ok {
        return def // 配置缺失 → 安全默认
    }
    if !cfg.Enabled {
        return false
    }
    return e.matchRules(cfg.Rules, ctx)
}

常见定向维度：
□ 用户 ID / 设备 ID 白名单：内测、特定客户
□ 用户属性：注册时长、活跃度、付费状态、地区
□ 百分比放量：hash(user_id + salt) % 100 < 比例
□ 组合条件：地区 = 华东 AND 活跃天数 > 7 AND 放量 20%

分桶的关键要求：
□ 稳定性：同一用户在同一开关下永远同一组
□ 正交性：不同开关用不同 salt，分桶互不干扰
□ 均匀性：哈希分布均匀，不出现某桶拥挤

分桶实现：
bucket = murmur3(user_id + ":" + flag_key) % 10000
命中   = bucket < rollout_percent * 100

为什么要用 flag_key 作 salt：
□ 若所有开关用同一个分桶，命中的用户完全重叠
□ 「总是在前 1% 的用户」会持续成为小白鼠 → 体验不公
□ 加 flag_key 后，不同开关的 1% 是不同的人群

放量阶梯（按风险决定每档与停留时长）：
内部用户 → 1% → 5% → 20% → 50% → 100%
□ 低风险（文案、样式）：可跳过中间档，直接 50%
□ 高风险（核心链路、计费）：每档停留 24 小时，人工确认
□ 每档都要看：错误率、延迟、崩溃率、业务指标

进入下一档的判据：
□ 错误率不高于基线 + 阈值
□ 延迟 P99 不劣化超过 10%
□ 无新增告警、无客服异常聚集
□ 业务护栏指标不劣化

自动中止（Auto-Rollback）：
□ 指标超阈值 → 自动把开关关回 0%
□ 需要「指标 → 开关」的联动（观测系统能写开关）

# 渐进交付的编排：每档带观测窗口与回退动作
stages:
  - name: internal
    rollout: 0            # 仅白名单
    dwell: 1h
  - name: canary
    rollout: 5
    dwell: 2h
    abort_if: { error_rate: "> 0.5%", p99_ms: "> 400" }
  - name: broad
    rollout: 50
    dwell: 6h
    abort_if: { error_rate: "> 0.3%", p99_ms: "> 300" }
  - name: full
    rollout: 100

Kill Switch 的设计要求：
□ 秒级生效：配置推送 + 本地缓存，不依赖重新部署
□ 高可靠：配置服务挂了也要能读到「关闭」指令
□ 有兜底：开关服务故障时的默认行为必须安全
□ 能自证：关闭后要有明确的效果（不只是「应该关了」）

典型 Kill Switch：
□ 关闭某类写操作（如发帖、评论）→ 保护数据库
□ 关闭昂贵功能（AI 生成、图片处理）→ 保护成本
□ 关闭外部依赖调用（第三方 API 故障时）→ 保护稳定性
□ 降级开关：切换到只读模式、静态兜底页

运维开关（Ops Flag）与发布开关的区别：
□ 运维开关是「长期能力」，要有监控与值班负责
□ 运维开关的变更要留痕（谁在什么时候关了什么）
□ 运维开关要演练（定期验证「关掉后是否真的降级成功」）
□ 运维开关与发布开关分属不同命名空间，避免混淆

区别：
□ 开关回答「给不给看」→ 关注「安全、可控、可回退」
□ 实验回答「哪个更好」→ 关注「分流、显著、可归因」
□ 开关是「一刀切」的放量；实验是「随机对照」的对比

配合模式：
□ 用实验开关做「带对照的放量」：对照组保持旧行为
□ 实验显著 → 用发布开关放量到全量（去掉对照）
□ 实验期间用实验开关分流；决策后用发布开关收口

常见误区：
□ 用发布开关「看数据」→ 没有对照组，无法归因
□ 用实验开关「长期放量」→ 对照组用户被永久剥夺新功能
□ 开关与实验各维护一套分桶 → 同一用户组别冲突

开关债的表现：
□ 僵尸开关：功能早已全量，开关还在，永远为 true
□ 嵌套地狱：开关套开关，逻辑难以理解
□ 死代码：永久关闭的开关背后是永不执行的代码
□ 组合爆炸：N 个布尔开关 = 2^N 种状态，测试无法覆盖
□ 无人认领：不知道开关是谁加的、能不能删

清理机制：
□ 出生即定死期：Release 开关创建时必须填「计划删除日期」
□ 定期扫描：自动列出「超过 X 天且长期恒为某值」的开关
□ 恒值检测：埋点统计开关的求值分布，长期 100% 或 0% 的标记
□ 清理 PR：删除开关时把两条代码路径合并，删除死分支

清理流程：
1. 扫描：列出所有 release 类开关及最后变更时间
2. 判定：恒为 true 且超过 30 天 → 候选删除
3. 收口：先把开关固化为「开」，观察一个周期
4. 删除：移除开关求值代码与死分支，合并逻辑
5. 回归：跑测试确认行为未变

命名规范：
□ 结构：<域>.<功能>.<类型>，如 feed.ranking_v2.release
□ 语义：名字表达「打开后发生什么」，而非「关闭后怎样」
□ 统一前缀便于按域扫描与权限控制

权限与审计：
□ 谁能创建开关？（一般：开发者可建，需审批）
□ 谁能改生产开关？（一般：受限角色，敏感开关双人复核）
□ 谁能删除开关？（需确认无引用）
□ 全量审计日志：谁、何时、把哪个开关、从什么值、改成什么值

审批与分级：
□ 普通开关：开发者自助
□ 高危开关（影响核心链路、计费、安全）：双人复核
□ 紧急开关（Kill Switch）：可单人操作，但事后必留痕

治理清单（每季度检查）：
□ 是否有无人认领的开关？
□ 是否有超过计划删除日期的 release 开关？
□ 是否有恒值的僵尸开关？
□ 高危开关是否有双人复核？
□ 是否有开关从未被任何代码引用（孤儿开关）？
□ Kill Switch 是否在演练中被验证过？