先说一个核心结论：在 Statsig 中，如果你希望针对某个具体的功能开关（Feature Gate），或者它内部的某一条规则（Rule），精细化地控制谁可以编辑、谁可以删除——目前这个需求无法直接实现。Statsig 仅提供项目级别的审批机制，例如团队审查（Team Reviews），但做不到类似“只允许 A 修改这条规则，B 不能动”这种细粒度的 RBAC（基于角色的访问控制）权限分配。
在实际的权限治理场景中，很多团队都希望实现类似以下的分权方式：
- 用户 A 可以自由修改 Feature-Gate-2 和 Feature-Gate-3；
- 但对于 Feature-Gate-1（包括它下面的所有规则，比如 Rule-1、Rule-2），他只有查看权限，不能编辑也不能删除；
- 而项目中的其他成员，却可以全权管理 Feature-Gate-1。
但遗憾的是，Statsig 当前的权限模型并不支持规则集（Ruleset）或单条规则（Rule）级别的访问控制。它的权限体系基于项目（Project）和环境（Environment），最细的粒度只能到“实体级审批流（Entity-level Reviews）”。也就是说，你可以对整个功能开关或实验的发布动作，强制要求人工审批——例如，必须至少有两位指定角色的成员批准才能上线。这个功能可以通过 Statsig 的审批配置文档启用，示例配置如下：
{ "reviewers": [ { "role": "admin", "minApprovals": 2 }, { "role": "security", "minApprovals": 1 } ], "appliesTo": ["feature_gate", "experiment"]}
⚠️ 关于这个限制，需要特别说明几点：
- Statsig 明确表示，规则本身没有独立的权限边界。因为规则是按执行顺序从上到下匹配的，上游规则可能完全覆盖下游规则的逻辑。如果只锁定 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 的项目隔离和成员角色绑定，实现粗粒度的权限分离。
- 流程卡点：启用实体级审批（Entity-level Reviews），在关键 Feature Gate 的变更路径上，插入强制审批节点。确保敏感配置的变更，必须经过指定角色审核才能生效。
- 外部协同管控：结合 CI/CD 流水线（比如 GitHub Actions）或内部的配置平台，在向 Statsig 推送配置之前，增加一道权限校验逻辑。这相当于在“配置即代码（GitOps）”的模式下，增加一个预检控制环节。
总的来说，Statsig 的设计哲学更侧重于“协作安全”和“发布可靠性”，而不是底层的规则级 RBAC。如果你的业务确实强依赖这种细粒度的规则权限，那么需要评估一下，是否可以通过架构拆分和流程强化，来达到等效的治理目标。
