权限设计混乱主因是模型未匹配业务节奏，需依场景选rbac、acl或混合模型；rbac适角色稳定系统，acl适细粒度资源控制，多租户须加tenant_id与scope字段；扩展性关键在permission拆resource/action、role加语义标记、user_role增时效字段；权限策略应代码化，通过yaml定义、引擎校验、内存加载实现解耦；重构宜分三阶段渐进迁移。
权限表设计混乱，本质不是字段没加全，而是模型没对齐业务变化节奏。RBAC不是万能模板，用错场景反而让问题更难解——比如把租户级隔离硬塞进标准三张关联表里，或给每个按钮都建一条权限记录。
先分清：你到底需要RBAC，还是ACL，或是混合模型
RBAC适合角色稳定、人员流动频繁的中后台系统；ACL更适合资源极细碎、每条数据都有独立Owner的场景（如文件系统、工单详情页）；而真实企业级SaaS往往得混合用：用RBAC管角色骨架，用ABAC补动态条件（比如“销售总监只能看本部门客户，且仅限工作日9–18点”）。
- 如果权限变动常以“一类人”为单位（如全体客服需新增导出报表权限），RBAC是正解
- 如果每次改权限都要精确到某张表某条记录（如“张三可编辑ID=123的合同”），那就该上ACL或带属性的ABAC
- 多租户系统别死守RBAC0，必须引入租户维度字段（tenant_id）和策略作用域（scope）字段，否则一张role_permission表会跨租户污染
五张基础表只是起点，关键在扩展字段的设计逻辑
标准RBAC的user、role、permission、user_role、role_permission五张表能跑通demo，但一上线就卡壳。真正决定扩展性的，是几个被忽略的字段：
- permission表里必须拆resource + action两列，而不是存一个字符串"order:export:all"——这样才方便做权限聚合（比如查所有order相关操作）、前端按模块过滤菜单
- role表加is_tenant_admin、is_system_admin等语义化标记字段，比在中间表里堆一堆“admin:global”权限更易审计
- user_role关联表里建议加effective_at / expires_at字段，支持临时提权、试岗期权限自动降级，避免靠人工回收
别让权限配置变成数据库运维活
权限改一次要找DBA执行SQL、改三次要写迁移脚本、改五次团队就开始绕开系统直接改代码——说明权限规则没脱离数据库。理想状态是：权限策略即代码。
- 把角色与权限映射关系收束到一份permissions.spec.yaml，CI流水线自动校验语法+冲突+最小权限原则
- 后端加载时生成内存策略树，不依赖实时JOIN查询；前端按resource分组拉取权限列表，减少接口耦合
- 租户管理员页面不直接操作role_permission表，而是调用策略引擎API提交变更请求，由引擎校验沙箱范围后再落库
重构不是推倒重来，而是分阶段切流
老系统权限表已堆积上千条记录，不能停服重做。可行路径是：
- 第一阶段：新建策略引擎服务，所有新功能权限走新链路，旧功能保持兼容
- 第二阶段：用策略引擎反向扫描历史权限数据，自动生成初始roles.yaml，并标注“待人工复核”标记
- 第三阶段：灰度切换，按租户/角色分批将鉴权逻辑迁入新引擎，监控403错误率与响应延迟
