drf的basepermission仅控制视图是否执行，不干预数据查询；数据过滤应在get_queryset中实现，或用django-filter；has_object_permission仅对单对象操作生效，列表接口需预过滤。
DRF的BasePermission不是万能开关，它只管“放不放行”，不管“怎么查数据”
权限校验和数据过滤是两件事。很多人以为重写has_permission就能控制用户看到哪些订单，结果发现列表接口返回了全部数据——因为BasePermission只决定视图是否执行，不干预queryset或get_queryset()。真正该动手的地方是视图类里的get_queryset，或者用django-filter配合自定义FilterSet做字段级收敛。
常见错误现象：has_permission返回True，但用户仍能看到不该看的数据；或返回False后前端只收到403，却没提示具体原因。
- 权限逻辑复杂时，优先在
get_queryset里做数据裁剪，比如return queryset.filter(creator=request.user) -
has_permission适合做粗粒度拦截（如“非管理员禁止访问此API”），别在里面拼SQL或调用.count() - 若需动态提示（如“你只能查看自己创建的订单”），改用
has_object_permission配合retrieve单条操作，或在序列化器里加to_representation逻辑
自定义Permission类里别直接查数据库，尤其别在has_permission里调User.objects.get()
Django REST Framework 的权限检查发生在请求生命周期早期，此时request.user已经解析完毕（只要用了SessionAuthentication或TokenAuthentication）。反复查库不仅慢，还可能触发AnonymousUser导致AttributeError。
使用场景：判断用户是否属于某部门、是否有某角色标签、是否在某项目组内。
- 用
request.user.groups.filter(name="finance").exists()代替Group.objects.get(name="finance") in request.user.groups.all() - 如果依赖外部服务（如LDAP角色同步），把校验逻辑下沉到
request中间件或auth_backends.py，避免每次API都远程调用 - 注意
request.user.is_authenticated必须显式判断，否则匿名用户进has_permission会崩
has_object_permission只对RetrieveAPIView、UpdateAPIView这类单对象操作生效
列表接口（ListAPIView）不会触发has_object_permission，哪怕你写了也白写。它只在retrieve、update、destroy等方法拿到具体obj实例后才调用。想控制列表里每条记录的可见性，得回到get_queryset做预过滤。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
参数差异：has_object_permission接收三个参数：self、request、view、obj；而has_permission只有前三个。
- 典型误用：在
ListAPIView里靠has_object_permission阻止用户看别人的数据 → 实际无效 - 正确做法：在
get_queryset中根据request.user动态返回子集，例如Project.objects.filter(members=request.user) - 如果对象级权限依赖多对多关系（如“用户是项目协作者或所有者”），用
Q组合条件，别写两个filter()链式调用，避免意外空结果
权限类叠加时，AND逻辑是默认行为，但OR得手动实现
DRF 默认把多个权限类当成“且”关系：只要一个返回False，整个请求就被拒。想实现“登录用户 或 管理员 可访问”，不能直接堆两个类，得写一个新类封装逻辑。
性能影响：叠加太多权限类会让每个请求多跑几次has_permission，尤其是含I/O的操作（如查Redis缓存角色）要格外小心。
- 简单
OR逻辑：在自定义类里写return user.is_authenticated or user.is_staff，别拆成两个类 - 兼容性注意：
IsAuthenticated和IsAdminUser本身不处理AnonymousUser的is_staff属性，自己写时记得先判is_authenticated - 测试时容易漏掉边界：比如
user=None（未认证）、user.is_active=False、user.profile is None，这些情况都要在权限类里覆盖
最麻烦的其实是权限和业务状态耦合——比如“订单已支付才能下载发票”，这种不属于DRF权限范畴，硬塞进has_object_permission会让权限类越来越重，不如拆到视图方法里单独校验。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
