题目重点：由管理面发布可审计规则，客户端按身份与 flag 的稳定 hash 本地评估，并明确失联时的陈旧配置与紧急关闭边界。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版支持布尔 flag、百分比分流、allowlist/blocklist 及环境/规则版本；需要看实例/用户/账号哪个 ID 作为分桶单位须由产品目标确定。
- SDK 可周期拉取签名/校验过的版本快照并本地决策；对客户端无法保密的规则或需要中心化审计的决策，需另考虑服务端评估。
- 故障默认值不是一律 false：每个 flag 指定安全 fallback 与最大可接受 staleness；紧急 kill switch 的传播时间必须在需求中明确。
解题路线
- 先问目标：发布灰度还是 A/B 测试、身份粒度、地域、延迟/可用性、紧急关闭要求、是否包含敏感规则。由这些需求决定本地还是远程评估，而不是套 rate limiter 模板。
- 控制面存 flag 定义、规则、版本、操作者和审批审计；验证规则冲突、签发不可变快照并推到对象存储/CDN。发布采用版本号与原子切换，失败可回滚到旧版本。
- SDK 定期拉快照，校验版本/完整性，先执行明确优先级的 blocklist、allowlist、条件规则、百分比 bucket、default。分桶使用 hash(flag key, salt, stable subject ID)→固定 0..9999 桶；同用户跨请求稳定，同一实验的多变体需互斥且分配总和不超 100%。
- 客户端失联可在 staleness TTL 内用最后好版本，到期走 flag 专属 fallback；高危 kill switch 若要求秒级传播，可另走推送/短轮询并监测实际到达率。日志记录 flag version、rule ID 和匿名化 bucket 以供诊断，不把完整用户属性滥收进日志。
- 容量估算从 SDK 实例数×拉取频率得控制面/CDN 流量，而不是用每一次业务请求打中心化评估服务；对千百 flag 的快照体积、增量更新、冷启动和多地域发布做预算。
手动走一遍
训练例 flag `new_checkout` 对账号 a123 在 10% 规则下 hash 桶为 732，因小于 1000 得 true；下次请求和另一服务的 SDK 读同一版本与 salt，也必须得 true。若 a123 在 blocklist，先执行 block 即 false；快照过期则按该 flag 指定 fallback，而非随机重新分桶。
规模与取舍
SDK 单 flag 评估在索引完毕后期望 O(规则匹配量)，hash O(ID 长度)；快照大小 O(F+规则项)，F 为 flag 数。发布传播滞后≈拉取周期+缓存/网络延迟；如需严格小于数秒，应证明每层上限与回滚路径。
易错点与追问
容易失分的边界
- 所有请求都走中心服务，却没有说明为何必须承担额外网络延迟与可用性依赖。
- 随机数逐请求决定灰度，使同一用户反复跳组。
- 只缓存配置不带版本，排障无法复现用户为何进入某变体。
- allow/block list 顺序不确定，规则冲突时 SDK 版本结果不同。
- 把紧急关闭说成即时，却采用数分钟轮询而无传播监控。
继续深挖
- 跨服务相同用户 ID 格式不一致时怎样保持同组？
- 实验改比例时，如何最小化老用户组别抖动？
- 敏感属性不能进入客户端 SDK 时，如何局部评估和服务端评估组合？
