django权限系统非rbac因缺少角色抽象层，需扩展group模型添加元信息，并通过角色校验替代权限直连，确保权限统一管理和审计。
为什么 Django 自带的权限系统不直接等于 RBAC
Django 的 auth.Permission 和 User.has_perm() 本质是“用户 → 权限”直连模型，缺少中间的角色抽象层。RBAC 要求权限必须通过角色（Role）间接赋予用户，且角色可复用、可批量分配、可动态解耦。直接用 user.user_permissions.add() 会绕过角色层，导致后期无法统一回收某类角色的所有权限，也难以审计“编辑商品”这个操作到底被哪些角色持有。
如何扩展 Group 模型支持角色元信息
Django 的 auth.Group 天然接近“角色”，但缺业务字段（如角色状态、适用系统模块、是否内置）。推荐继承 Group 或用一对一关联扩展，而非完全自建 Role 模型——避免重复维护组名唯一性、权限多对多关系等底层逻辑。
实操建议：
- 新建
models.py中定义Role模型，OneToOneField(Group, on_delete=models.CASCADE)关联原生 Group - 添加
is_active、scope（如'admin'/'seller'）、description等字段 - 在 Admin 中注册
Role，同时重写GroupAdmin的form，隐藏原生 Group 的权限字段，改由 Role 页面统一管理 - 所有权限分配必须走
role.group.permissions.add()，禁止直接操作User.user_permissions
如何在视图中校验角色而非单个权限
用 @permission_required 或 PermissionRequiredMixin 是检查具体权限字符串（如 'shop.change_product'），不是角色。要实现“仅允许 seller 角色访问商品管理页”，需自定义校验逻辑。
实操建议：
- 写一个工具函数
user_has_role(user, role_name)，内部查user.groups.filter(name=role_name).exists() - 在 CBV 中重写
dispatch()，或封装成 mixin：class RoleRequiredMixin:，用self.request.user.groups.filter(name__in=self.required_roles).exists() - 若需细粒度控制（如“seller 角色中仅启用库存管理模块的用户”），可在
Role模型里加 JSONField 存模块开关，校验时一并读取 - 注意：Django 缓存了
user.groups查询结果，频繁调用不会重复查库，但跨请求仍需重新加载
如何让模板里安全地显示角色相关 UI 元素
模板中不能写 {% if user.has_perm 'shop.delete_product' %} —— 这又退回到了权限直连，破坏 RBAC 结构。应基于角色做判断，且避免硬编码角色名。
实操建议：
- 在 context_processor 中注入
user_roles = list(user.groups.values_list('name', flat=True)) - 模板中用
{% if 'seller' in user_roles %}控制按钮显示，比查权限更符合 RBAC 语义 - 若角色名可能变化（如从
'seller'改为'merchant'），建议在Role模型中加code字段（唯一、不变），模板中查role_code而非name - 不要在模板里做复杂逻辑，比如“有 seller 或 admin 才显示导出按钮”，应提前在 view 中计算好布尔值传入 context
真正难的不是建模，而是约束团队所有开发者只通过角色增删权限、不在代码里写死 user.user_permissions；还有就是历史用户迁移——老用户可能直接绑了权限，得写脚本把他们归入对应角色组。这些事没自动化，RBAC 很快就退化成假 RBAC。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
