django内置权限系统更稳妥，因其已实现符合rbac核心原则的group-permission-user三者关系及数据库约束；自研易遗漏content_type校验、superuser优先级、迁移丢失等隐性问题。
为什么直接用django内置权限系统比自己造rbac轮子更稳妥
django自带的auth模块已实现角色（group）、权限（permission）、用户（user）三者关系，底层是多对多关联+数据库约束，不是伪rbac而是符合rbac核心原则（角色绑定权限、用户绑定角色）的轻量级实现。自己从零设计表结构容易漏掉content_type动态权限校验、is_superuser与角色权限的优先级冲突、迁移时权限丢失等隐性问题。
常见错误现象：user.has_perm('app_label.action_model')返回False但明明已加到Group里——大概率是没执行python manage.py migrate后忘记运行python manage.py createsuperuser或python manage.py loaddata初始化权限；或者自定义Model没在INSTALLED_APPS中注册，导致ContentType未生成。
- 权限粒度默认到Model级别（如
add_user），若需字段级控制（如只读email字段），得配合自定义ModelAdmin或中间件拦截，不建议在RBAC层硬改 -
Group不能嵌套（即A组不能属于B组），需要层级关系时，要么用django-group-admin扩展，要么在业务逻辑里手动递归查子角色 -
is_staff=True只是控制能否登录admin后台，和权限无直接关系；is_superuser=True会绕过所有权限检查，慎用
如何给视图函数加权限装饰器而不写重复代码
用@permission_required最直接，但它只能处理GET请求且跳转到登录页——实际项目中常需API返回403 JSON、或区分“无权限”和“未登录”。这时候该用user.has_perm()手动判断，再结合HttpResponseForbidden或DRF的PermissionDenied异常。
示例场景：一个编辑文章接口，要求用户有blog.change_article权限：
from django.http import HttpResponseForbidden
from django.contrib.auth.decorators import login_required
<p>@login_required
def edit_article(request, article_id):
if not request.user.has_perm('blog.change_article'):
return HttpResponseForbidden('No permission')</p><h1>...业务逻辑</h1>
注意：has_perm()内部会检查用户是否在对应Group里，也会检查is_superuser，无需额外判断。
- 避免在模板里大量用
{% if perms.blog.add_article %}——权限逻辑应尽量收口到View或Serializer，模板只负责渲染 - REST Framework中推荐用
IsAuthenticated+ 自定义BasePermission子类，重写has_permission()方法，便于单元测试 - 权限字符串里的
blog必须是App名（不是目录名），且Model类名首字母大写，比如Article对应change_article
如何批量分配权限给角色并保证上线不翻车
别在Django Admin界面点点点——生产环境权限变更必须可追溯、可回滚。正确做法是写django.core.management.Command脚本，用Group.objects.get_or_create()和group.permissions.set()批量操作，再把脚本放进migrations/目录作为数据迁移文件。
关键点：权限对象必须通过Permission.objects.get(codename='xxx', content_type__app_label='yyy')获取，不能直接传字符串。因为同一codename在不同App下是不同权限。
- 首次部署时，确保
python manage.py migrate已执行，否则ContentType为空，查不到Permission - 如果用
loaddata导入权限，JSON文件里content_type字段必须是app_label.model_name格式（如"auth.user"），且ID要和目标库一致，否则外键报错 - CI/CD流程中，在
migrate步骤后自动运行权限初始化命令，避免人工漏操作
为什么Django的Permission对象不能直接存业务字段如“部门ID”
Permission模型只有name、codename、content_type三个字段，设计上就只管“能做什么”，不管“对谁做”。想实现“销售部员工只能看本部门客户”，得在View或QuerySet里加过滤条件，比如Customer.objects.filter(department=request.user.profile.department)，而不是试图往Permission表里塞department_id字段。
强行扩展Permission会导致auth_group_permissions表外键失效、admin权限管理页崩溃、第三方包兼容性问题。真有复杂授权需求（如ABAC），该换django-rules或django-guardian（支持对象级权限）。
-
django-guardian的assign_perm('change_customer', user, customer_obj)适合单条记录授权，但千万注意：它不替代Group权限，而是叠加生效 - 所有带业务上下文的权限判断，务必放在数据查询层（如Manager或ViewSet的
get_queryset()），避免在模板或前端JS里拼接条件 - 缓存权限结果时，别用全局变量存
user.get_all_permissions()——用户角色变更后不会自动失效，得监听user.groups信号清缓存
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
