Django内置Group和Permission足以支撑基础RBAC，关键在于权限粒度设计（按“模型+操作”命名）、角色与业务对齐、代码固化分配、合理选用@permission_required或user.has_perm()、对象级权限通过模型方法或get_queryset()实现，并重视迁移时权限同步。
用 Django 的 Group 和 Permission 做基础 RBAC 就够用了
Django 自带的认证系统已经内置了角色（Group）和权限（Permission）模型，不需要额外装包或重写用户模型就能支撑典型 RBAC 场景。关键不是“能不能做”，而是怎么组织权限粒度、谁来分配、以及视图层怎么校验。
常见错误是把所有权限都塞进 Group，结果后期改一个角色就得手动同步几十个视图的装饰器；或者直接在模板里用 {% if perms.app_label.add_model %} 硬编码权限名，导致迁移或重命名时大面积报错。
- 权限应按「数据模型 + 操作」定义，比如
blog.change_post、order.delete_order，而不是按页面或功能模块起名 - 一个
Group对应一个业务角色（如"editor"、"support_agent"），不要建"can_edit_post_title"这种细粒度 Group - 权限分配必须通过代码（
manage.py loaddata或 migrations）固化，避免后台手动勾选——线上环境没人能保证每次部署都手动同步
@permission_required 和 user.has_perm() 的区别与适用场景
@permission_required 是快捷但僵硬的方案：它只支持字符串权限名、默认跳转到登录页、不支持组合逻辑（比如“有 A 权限或 B 权限”）。而 user.has_perm("app_label.codename") 更灵活，能嵌入任意条件判断中，也便于单元测试模拟。
实际开发中，函数视图优先用 @permission_required 快速兜底；类视图（尤其是 View 或 TemplateView）建议在 dispatch() 里调用 has_perm()；API 视图（DRF）则必须自己写校验逻辑，因为 DRF 的 Permission 类不认 Django 原生 Permission 对象的字符串匹配规则。
立即学习“Python免费学习笔记（深入）”；
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
-
@permission_required("blog.publish_post", raise_exception=True)—— 加raise_exception=True避免静默跳转到 login 页面 -
if not request.user.has_perm("blog.view_draft_post"):—— 可配合get_object_or_404()做对象级控制 - 注意：
has_perm()对匿名用户返回False，无需额外判is_authenticated
自定义权限逻辑要绕开 auth.Permission 表硬编码
当权限依赖运行时数据（比如“只能编辑自己创建的文章”），不能靠 auth.Permission 表管理——那张表只存静态权限声明。这类逻辑必须在视图或模型方法里实现，且要统一入口，避免散落在多个 if 判断中。
推荐做法是在模型上加方法（如 Post.can_edit_by(user)），并在视图中调用；或者用 Django Guardian 做对象级权限（但会引入新表和查询开销，小项目慎用）。
- 别在视图里重复写
post.author == request.user，抽成模型方法后，未来加审核状态、团队归属等条件只需改一处 - 如果用 DRF，把对象级检查放进
get_queryset()而不是retrieve()，否则列表页可能漏过滤 - 数据库查询尽量复用已有的
select_related或prefetch_related，避免因权限检查触发 N+1 查询
迁移权限时最容易被忽略的两件事
权限不是写完代码就自动注册的。Django 只在运行 makemigrations 时扫描 Meta.permissions 并生成对应记录，但不会自动同步到已有数据库。很多团队上线后发现新权限不起作用，就是因为没跑 python manage.py migrate，或者没清空旧权限再重载。
- 新增模型权限后，必须执行
python manage.py migrate，否则auth_permission表里没有对应行 - 修改已有权限名（比如从
"change_article"改成"change_post"），旧记录不会自动更新，得手动删或用 migration 清理 - 用
loaddata初始化权限时，确保 fixture 文件里的content_typeID 与目标环境一致，否则会报IntegrityError: insert or update on table "auth_permission" violates foreign key constraint
权限逻辑越靠近数据层，越容易被绕过；越分散在模板、视图、序列化器里，越难维护。真正卡住边界的，永远是那个在 get_queryset() 里悄悄 filter 掉非本人数据的语句。
