Django默认权限系统仅支持模型级控制，需借助django-guardian或自定义PermissionBackend实现对象级权限；DRF中须在get_queryset等处显式校验对象权限，避免越权。
django.contrib.auth 权限系统默认只到 model 级，不够用
Django 自带的 add_、change_、delete_、view_ 这四类权限，绑定在 ContentType 和 User/Group 上，本质是「某个用户能否对某张表执行某类操作」。它不支持「张三能改自己发的文章，但不能改李四的」，也不支持「编辑部成员可发布草稿，但只有主编能发布正式版」这类规则。
常见错误现象：user.has_perm('blog.change_article') 返回 True，结果用户一提交编辑就 403 —— 因为视图里没做对象级校验，或者用了 get_object_or_404 却没配合 user.has_perm('blog.change_article', obj)。
- 必须显式启用对象级权限：在
Model中继承PermissionsMixin不够，得用第三方库（如django-guardian）或手写has_object_permission -
django.contrib.auth的权限检查函数（如has_perm）默认不查对象，加第二个参数obj才触发对象级逻辑，且要求后端支持 - 如果不用
django-guardian，就得在每个视图/serializer 中重复写判断逻辑，容易漏、难维护
用 django-guardian 实现 RBAC 风格的对象权限分配
django-guardian 是目前最轻量、兼容性最好的对象级权限方案，它把「谁对哪个对象有什么权限」存成独立模型 UserObjectPermission / GroupObjectPermission，和 Django 原生权限系统共存，不破坏现有逻辑。
使用场景：需要按部门/角色动态授权具体数据（比如「华北区销售只能看华北客户」、「实习生只能编辑自己提交的 PR」）。
- 安装后必须在
INSTALLED_APPS加'guardian'，并设ANONYMOUS_USER_NAME = None（否则匿名用户会意外获得对象权限） - 给模型开启对象权限：在
Meta里加permissions = [('view_own_article', 'Can view own article')]，再运行python manage.py migrate - 分配权限别用
assign_perm('blog.change_article', user, article)直接硬编码，建议封装成服务函数，统一处理权限继承（比如给部门 Group 授权，自动同步到下属用户）
自定义 PermissionBackend 是绕过 guardian 的替代方案
如果你不想引入新依赖，或权限规则高度动态（比如「用户 A 能编辑 B 的文章当且仅当 A 是 B 的上级，且 B 的文章状态为 draft」），直接重写 has_perm 更灵活。
性能影响明显：每次 user.has_perm() 都会调用你写的后端，若里面含数据库查询或远程调用，可能拖慢所有带权限检查的接口。
- 必须继承
django.contrib.auth.backends.ModelBackend，重写has_perm(self, user_obj, perm, obj=None) - 当
obj is not None时才做对象级判断；返回None表示「不处理这个权限请求」，让下一个 backend 继续试 - 注意缓存：复杂规则建议用
cache.get(f'perm_{user_id}_{obj_id}_{perm}')缓存结果，避免重复计算 - 别在 backend 里抛异常，Django 会静默吞掉，导致权限永远返回
False
ViewSets 和 DRF Serializer 中权限校验最容易漏的点
DRF 的 permission_classes 默认只校验 view 层（比如整个 ArticleViewSet 是否可访问），不会自动校验每个 article 实例。很多团队卡在这儿，API 看似有权限控制，实则对象越权泛滥。
常见错误现象：ListAPIView 返回了 200，但列表里混入了用户无权查看的 article；RetrieveAPIView 对某个 ID 返回 404，不是因为不存在，而是权限不足但没返回 403。
- 在
get_queryset()里过滤数据，而不是靠前端传参或事后检查：用filter(user= request.user)或filter(id__in=get_user_accessible_ids(request.user)) - Serializer 的
to_representation不做权限裁剪，敏感字段（如is_paid、internal_note）得在fields动态控制，或用SerializerMethodField包一层检查 - 别依赖
request.user.is_authenticated当权限开关——登录了不等于有权限，尤其在多租户或跨组织场景下
事情说清了就结束。RBAC 在 Django 里从来不是开箱即用的功能，核心矛盾在于：原生权限是静态的、模型级的，而真实业务要的是动态的、实例级的、带上下文的。选 django-guardian 还是自研 backend，取决于你的规则复杂度和团队维护成本预期——但无论如何，has_perm(..., obj) 这个调用本身，以及它背后是否真有实现，才是最容易被跳过的那一环。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
