Django自带User和Group不够用，因其权限模型仅支持“用户→组→权限”单层映射，无法满足多租户、带作用域的角色需求；需自建Role、Permission、RoleAssignment三模型解耦角色与权限，并引入content_type/object_id实现动态作用域。
为什么直接用 Django 自带的 User 和 Group 不够用？
Django 的 auth 框架提供 User、Group 和 Permission，但默认只支持“用户 → 组 → 权限”单层映射。真实业务中常需要：同一用户在不同项目/租户下角色不同（如 A 用户在项目 X 是管理员，在项目 Y 是只读成员）；或角色带参数（如“可编辑自己提交的工单”）。硬塞进 Group 会导致组爆炸、复用困难、无法动态绑定上下文。
所以得自己建模，核心是解耦「角色」和「权限」，并引入作用域（scope）概念。
- 不把权限硬编码到
Group名称里（比如叫project_x_admin），而是用模型字段控制范围 - 避免重写
has_perm()全局方法——它没法接收额外参数（如project_id） - 别在视图里手动查
user.groups.filter(...)判断——重复逻辑难维护，且绕过 Django 的权限缓存机制
怎么设计最小可行的角色模型结构？
关键不是堆字段，而是明确三个实体及其关系：角色（Role）、权限项（Permission）、角色分配（RoleAssignment）。Django 的 auth.Permission 仍可用作底层原子权限，但不再直接绑给 Group。
示例模型：
立即学习“Python免费学习笔记（深入）”；
class Role(models.Model):
name = models.CharField(max_length=100) # 如 "ProjectAdmin", "TeamMember"
permissions = models.ManyToManyField('auth.Permission', blank=True)
<p>class RoleAssignment(models.Model):
user = models.ForeignKey('auth.User', on_delete=models.CASCADE)
role = models.ForeignKey(Role, on_delete=models.CASCADE)
content_type = models.ForeignKey(ContentType, on_delete=models.CASCADE) # 作用域类型，如 Project
object_id = models.PositiveBigIntegerField() # 作用域实例 ID，如 project.id
content_object = GenericForeignKey('content_type', 'object_id')</p>这样设计后，判断“用户 U 是否对 Project P 有编辑权限”，就变成：
- 查
RoleAssignment找出 U 在 P 上的所有role - 查这些
role.permissions是否包含project.change_project - 用
django.contrib.auth.models.Permission的 codename，保持和 admin、user.has_perm()兼容
如何在视图和模板里安全调用权限检查？
别在每个视图里手写查询。封装一个可复用的检查函数，接受 user、perm（字符串，如 "project.delete_project"）、obj（作用域对象）：
def has_role_perm(user, perm, obj):
if not user.is_authenticated:
return False
ct = ContentType.objects.get_for_model(obj)
assignments = RoleAssignment.objects.filter(
user=user,
content_type=ct,
object_id=obj.pk
).select_related('role').prefetch_related('role__permissions')
for assignment in assignments:
if assignment.role.permissions.filter(codename=perm.split('.')[-1]).exists():
return True
return False
在视图中用法：
- CBV 中重写
dispatch()或用 mixin：if not has_role_perm(self.request.user, 'project.change_project', self.get_object()): raise Http404 - 模板中用自定义 filter：
{% if user|has_role_perm:"project.delete_project" project %}...{% endif %}（filter 内部调用同上函数） - 注意：
perm字符串必须含 app_label，但函数只比对 codename——这是为了兼容 Django 原生权限系统，避免重复定义
容易被忽略的缓存与性能陷阱
每次请求都查数据库会拖慢响应，尤其当一个用户在多个项目中有角色时。Django 的 user.get_all_permissions() 缓存的是全局权限，对带 scope 的角色无效。
- 不要用
@cached_property直接缓存在User实例上——多线程下可能污染 - 推荐用
cache.get_or_set()，key 包含user_id+obj_type+obj_id+perm_codename，超时设为 5–10 分钟 - 权限变更时主动失效缓存：在
RoleAssignment.save()或delete()里触发cache.delete_pattern(...) - 如果项目数多、角色频繁变动，考虑用 Redis 的 set 结构存“用户→[role_id]”映射，再查 role 的权限——比 ORM join 更快
真正麻烦的不是建模，而是所有权限检查点（API、admin、表单字段、甚至信号）都要统一走这套逻辑。漏掉一个地方，就等于留了后门。
