rbac模型通过用户、角色、权限、资源四元素解耦权限管理，用户经角色间接获权；django用user-group-permission实现，可扩展group、集成django-guardian支持实例级控制，并须在视图、api等服务端环节严格校验权限。
RBAC模型的核心结构
RBAC（基于角色的访问控制）把权限管理拆成四个基本元素：用户、角色、权限、资源。用户不直接绑权限，而是通过角色间接获得权限；一个用户可有多个角色，一个角色可分配多个权限，权限则对应具体操作（比如“编辑文章”“删除订单”）。这种解耦让系统更灵活——换岗时只需调整角色，不用逐个改用户权限。
用Django实现RBAC的常用方式
Django自带的auth模块已内置User、Group、Permission三类模型，天然适配RBAC基础逻辑：
- User 表示系统用户，不存权限字段，靠关联获取
- Group 对应“角色”，比如“内容编辑员”“财务管理员”
- Permission 是预定义的操作单元，格式为app_label.codename（如blog.change_post）
- 给Group分配Permission，再把User加入Group，权限就生效了
实际开发中常扩展Group模型（如加描述、启用状态），或用ContentType动态绑定权限到具体数据实例（实现行级控制）。
进阶：支持资源实例级权限（ABAC+RBAC混合）
纯RBAC只能控制“能否编辑文章”，无法区分“能否编辑自己写的那篇文章”。这时可在权限判断中加入上下文：
立即学习“Python免费学习笔记（深入）”；
- 自定义装饰器或Mixin，检查request.user == obj.author
- 用django-guardian库实现对象级权限，每个Model实例可单独授权
- 结合组织架构（如部门树），在角色基础上叠加数据范围过滤（如“仅查看本部门订单”）
权限校验的关键时机与写法
权限不是只在菜单渲染时检查，必须在每次敏感操作前验证：
- 视图层：用@permission_required('blog.delete_post')或LoginRequiredMixin + UserPassesTestMixin
- 模板层：用{% if perms.blog.delete_post %}控制按钮显隐（但只是体验优化，不能替代后端校验）
- API接口：DRF中用IsAuthenticated & DjangoModelPermissions，或自定义BasePermission子类做细粒度判断
特别注意：所有权限判断必须走服务端，前端隐藏按钮≠权限控制。
