权限校验核心是判断当前用户是否被允许访问该视图，而非仅检查登录态；需用request.user.has_perm()或角色查询（如user.groups.filter(name='admin').exists()），确保权限已分配且模型已迁移，并区分fbv与cbv的装饰器用法，api接口应返回json错误而非重定向。
装饰器里怎么判断用户有没有权限
权限校验的核心不是“用户是否登录”，而是“当前请求的用户是否被允许访问这个视图”。Django自带的 @login_required 只管登录态，不处理角色或权限粒度。真正做接口权限控制，得靠 request.user.has_perm() 或自定义逻辑。
常见错误是直接在装饰器里硬写权限字符串，比如 'app.add_model'，但没确认该权限是否真被分配给了用户或其所属组——结果永远返回 False。必须确保：用户模型已同步权限（python manage.py migrate）、权限已通过 Group.objects.get(name='xxx').permissions.add(...) 或 admin 页面分配。
- 用
request.user.has_perm('app_name.permission_codename')判断具体权限 - 若按角色（如 'admin'、'editor'）控制，建议查
request.user.groups.filter(name='admin').exists()，比硬编码权限更易维护 - 装饰器中别调用
get_object_or_404或数据库-heavy 操作，避免每次请求都查库；可提前缓存角色信息到 session 或用信号预加载
装饰器怎么兼容 FBV 和 CBV
函数视图（FBV）直接套装饰器没问题，但类视图（CBV）不能直接在类上加 @permission_required，否则会报 TypeError: 'MyView' object is not callable。Django 官方推荐用 method_decorator 包裹，且必须明确指定作用在哪个方法上。
容易踩的坑是把装饰器加在类定义前却不指定方法，或者用了 @method_decorator 却忘了传 name='dispatch' ——结果权限校验根本没触发。
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- FBV：直接用
@my_permission_required('app.view_post') - CBV 方法级：用
@method_decorator(my_permission_required('app.change_post'), name='post') - CBV 全局（整个类）：用
@method_decorator(my_permission_required('app.delete_post'), name='dispatch') - 别用
@permission_required原生装饰器处理 API 接口，它默认重定向到 login 页面，而 DRF 或 REST 接口需要返回 JSON 错误响应
如何让装饰器返回标准 JSON 错误而不是跳转
Django 默认权限失败时走重定向（HttpResponseRedirect），这对前后端分离项目完全不可用。装饰器必须自己构造 JsonResponse 并设置状态码为 403。
关键点在于：不要依赖 PermissionDenied 异常自动触发 403 页面（那是中间件行为），而要主动拦截并响应。同时注意 Content-Type 和 CORS 兼容性——如果前端发的是 preflight 请求，装饰器不能在 OPTIONS 方法里执行权限检查。
- 检查
request.method == 'OPTIONS'时直接return JsonResponse({}, status=200) - 权限失败时用
return JsonResponse({'detail': 'Permission denied'}, status=403) - 别在装饰器里 import
JsonResponse太晚——应放在模块顶部，避免循环引用 - 如果项目用了 Django REST Framework，优先考虑用
APIView.permission_classes，比手写装饰器更统一、支持 permission 合并逻辑
装饰器里怎么拿到 URL 参数或请求体里的资源 ID
很多权限是“仅能操作自己创建的数据”，比如 /api/posts/123/ 要校验用户是否是 post.id=123 的作者。但装饰器运行在视图函数执行前，kwargs 是有的，request.body 却还没被解析——你拿不到 JSON 里的 user_id 字段。
所以别试图在装饰器里解析 request.body，也不要在装饰器里做 ORM 查询（如 Post.objects.get(id=kwargs['pk'])）。正确做法是把权限校验逻辑下沉到视图内部，或用带参数的装饰器接收字段名，再由视图传入实例。
- 装饰器只负责“框架层”校验（如登录、角色、基础权限），细粒度对象级权限交给视图或自定义 Permission 类
- 如果非要用装饰器做对象级检查，用
kwargs.get('pk')或kwargs.get('slug')提取 URL 参数，再查 DB（但要注意 N+1 问题） - 对 POST/PUT 请求，把校验逻辑移到视图的
perform_create或perform_update中更安全、更清晰
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
