功能开关机制需要支持按用户维度独立启停
别名: 按用户功能开关 · feature flag 独立启停 · user-dimension toggles
概念解释
灰度若只能按版本包或按服务器切，就无法把某个用户、某类设备或某个组织单独拉进或拉出试验。功能开关（feature flag / feature toggle）要把启停落在用户维度（以及与用户绑定的账号、设备、租户）上，并且彼此独立：开交互 A 不必连带开交互 B，停一个人不必停整台服务器。Humble 与 Fowler 讨论的 feature toggle 首先是工程解耦，对评估而言它是可操作的实验单元。没有按用户独立启停，回滚和分层抽样都做不到细。
机制
交互评估需要的对照发生在人这一层：同一天里有的人看到新流程，有的人没有；某位投诉者必须能被单独关掉，而不惩罚同机房的其他人。若开关绑在构建或机房，启停的粒度变成基础设施事件，体验问题无法被隔离，试点组织也无法与相邻组织分开。独立性还防止“大爆炸开关”：一串未验证的交互被同一个旗标捆住，一开全开，失败无法归因。按用户寻址要求身份稳定——匿名、多设备、共享账号会让同一人重复进出，污染阶段统计。开关本身也必须快：若关闭要重新发版，判断点只是名义上的。
怎么研究
把开关矩阵当作方法描述的一部分：维度（用户、组织、设备）、默认态、变更延迟、谁有权限改。审计一次真实回滚：从判定到目标用户失去新路径花了多久、误伤了谁。比较研究可看“只能按百分比随机”与“可按分层指定用户”在问题定位上的差异。日志必须写下每次开关变更的操作者与范围，否则阶段数据不可解释。评估计划应禁止用未文档化的临时开关。
边界
没有稳定身份的产品（一次性会话、公共终端）无法真正按用户启停，只能按会话或按设备近似，解释要写明。企业产品的租户开关可能比个人开关更合适，但租户内的个人差异会被抹平。合规要求全员同时切换的功能（计税、合同条款）不能用按用户灰度。开关爆炸会变成配置债务，独立性需要治理，而不是无限加旗标。客户端缓存会导致“已关仍看见”，独立启停在协议上成立、在体验上滞后。
怎么落地
- 每个被评估的交互一个旗标，默认关，寻址键是用户或租户，而不是构建号。
- 值守手册写明如何在分钟级关掉单个用户和整层用户，并演练一次。
- 变更写入审计日志，评估报告附上时间线。
- 发现无法按用户停，就把该功能从灰度名单拿掉，改走需停机的试点，而不是假装已有开关。