为何Django部分POST请求未触发CSRF警告？自定义用户模型与has_perm设置的关联排查

让我一步步帮你理清这些问题，结合DRF和Django的核心机制来解释：

1. 为什么登录请求（TokenObtainPairView）未触发CSRF警告？ #

DRF的CSRF检查逻辑和Django原生视图不一样——它是根据视图使用的认证类来动态决定是否启用保护的：

• TokenObtainPairView是SimpleJWT专门用来生成登录token的接口，它默认用AllowAny权限类，不需要任何前置认证（毕竟用户还没登录呢）。
• CSRF本质是针对session会话认证的防护手段，用来防止跨站请求伪造用户的会话。而JWT属于无状态的token认证，不存在伪造session的风险，所以DRF会自动跳过这类无状态接口的CSRF检查，哪怕你没带令牌也能正常请求。

2. 该现象是否与自定义用户模型相关？若相关，遗漏了哪些配置？ #

直接关联不大，但可能是间接影响：

• 两个项目的核心差异大概率不在自定义用户模型本身，而是DRF的全局认证配置（也就是settings.py里的DEFAULT_AUTHENTICATION_CLASSES）。
• 使用基础用户模型的项目里，DRF默认会把rest_framework.authentication.SessionAuthentication加入认证类列表。当你的“添加标题”视图用到这个认证类时，DRF就会强制检查CSRF令牌；而自定义用户模型的项目中，你可能移除了SessionAuthentication，只保留了SimpleJWT的认证类，所以所有接口都不需要CSRF检查。
• 你提到的重写has_perm和has_module_perms方法返回True，这个只会让你的自定义用户拥有所有模型和模块的权限（相当于超级用户），但和CSRF机制完全没关系，不是导致差异的原因。

3. 问题成因推测与学习方向 #

成因总结 #

CSRF警告出不出现，核心看当前请求是否依赖SessionAuthentication：

• 如果接口用的是SessionAuthentication（比如Django原生登录、DRF默认配置下的会话认证），就必须带CSRF令牌；
• 如果接口用的是无状态认证（比如JWT、TokenAuthentication），DRF会自动跳过CSRF检查。

对应你的场景：

• 登录接口（TokenObtainPairView）不需要任何认证，自然跳过CSRF；
• 基础用户模型项目的“添加标题”视图依赖SessionAuthentication，所以触发警告；
• 自定义用户模型项目的所有接口都用JWT认证，因此从未触发警告。

学习关键词（方便你深入研究） #

• Django CSRF中间件工作原理
• DRF认证类与CSRF的关联逻辑
• SimpleJWT认证流程
• Django自定义用户模型权限系统

内容的提问来源于stack exchange，提问作者Melly