statsig 目前不支持针对单个功能开关（feature gate）或其内部规则（rule）设置角色级编辑/删除权限，仅提供项目级或实体级审批机制（如 team reviews），无法实现“仅限制某用户修改特定规则”的精细化 rbac 控制。
statsig 目前不支持针对单个功能开关（feature gate）或其内部规则（rule）设置角色级编辑/删除权限，仅提供项目级或实体级审批机制（如 team reviews），无法实现“仅限制某用户修改特定规则”的精细化 rbac 控制。
在实际的权限治理实践中，许多团队期望实现类似以下场景的精细化管控：
- 用户 user-1 可自由编辑 Feature-Gate-2 和 Feature-Gate-3；
- 但对 Feature-Gate-1（及其下所有规则，如 Rule-1、Rule-2）仅拥有只读权限，禁止编辑或删除；
- 同一项目内其他成员则可全权管理 Feature-Gate-1。
遗憾的是，Statsig 当前的权限模型不支持规则集（Ruleset）或单条规则（Rule）级别的访问控制。其权限体系基于项目（Project）和环境（Environment）维度，最高可细化至「实体级审批流（Entity-level Reviews）」——即对整个功能开关（Feature Gate）或实验（Experiment）的发布行为强制引入人工审批（例如要求至少两名指定角色成员批准后方可上线）。该能力可通过 Statsig 审批配置文档 启用，示例配置如下：
{
"reviewers": [
{ "role": "admin", "minApprovals": 2 },
{ "role": "security", "minApprovals": 1 }
],
"appliesTo": ["feature_gate", "experiment"]
}
⚠️ 关键限制说明：
- Statsig 明确指出，规则（Rule）本身不具备独立权限边界。因为规则按执行顺序（从上到下）匹配，上游规则可能完全覆盖下游规则逻辑。若仅锁定 Rule-1 而允许修改 Rule-2，可能导致 Rule-1 的业务意图被间接绕过，使权限控制失去实际意义；
- 所有规则均隶属于同一 Feature Gate 实体，Statsig 将其视为不可分割的配置单元，因此权限操作只能作用于整个 Feature Gate，而非其子规则；
- 若需隔离敏感配置，推荐做法是：将高权限要求的功能拆分为独立的 Feature Gate（如 payment-verification-v2），并通过项目分组 + 成员角色分配 + 审批流三重机制进行隔离。
✅ 可行替代方案建议：
- 语义化拆分：将需差异化管控的功能逻辑拆为多个 Feature Gate（如 feature-a-prod-only, feature-a-beta-only），再通过 Statsig 的项目（Project）隔离 + 成员角色绑定实现粗粒度权限分离；
- 流程卡点：启用 Entity-level Reviews，在关键 Feature Gate 的变更路径中嵌入强制审批节点，确保敏感配置变更必须经由指定角色审核；
- 外部协同管控：结合 CI/CD 流水线（如 GitHub Actions）或内部配置平台，在推送 Statsig 配置前增加权限校验逻辑，实现「配置即代码（GitOps）」模式下的预检控制。
综上，Statsig 的设计哲学更侧重于协作安全与发布可靠性，而非底层规则级的 RBAC。如业务强依赖细粒度规则权限，建议评估是否可通过架构拆分与流程强化达成等效治理目标。
