DRF默认已CSRF防护，@method_decorator(csrf_protect)的作用是什么？

首先得纠正一个常见误解：DRF的APIView并不是对所有POST/PUT/DELETE请求默认开启CSRF防护的，它的防护逻辑分场景：

• 如果视图用的是Session认证（比如用户登录后依赖cookie+session的场景），DRF会自动启用CSRF防护，和Django普通视图规则一致，必须携带CSRF token才能通过校验。
• 如果用的是非Session类认证（比如Token、JWT认证），DRF会自动跳过CSRF防护——因为这类认证不依赖cookie，CSRF攻击的前提不成立。

回到你的问题，有人在APIView上手动加@method_decorator(csrf_protect)，通常是这几种原因：

• 强制覆盖默认规则：比如某些场景下同时支持多种认证方式，但希望不管用哪种，都必须校验CSRF token，手动加装饰器就能强制开启防护，不受DRF默认逻辑影响。
• 代码可读性优先：有些开发者为了让代码意图更明确，特意加上装饰器，让后续维护的人一眼就知道这个视图有CSRF防护，不用去回忆DRF的默认规则。
• 旧教程的遗留习惯：早期DRF版本的CSRF防护逻辑和现在有差异，有些老教程沿用了当时的写法，虽然现在对Session认证的视图来说是冗余操作，但也不会产生负面影响。

看你贴的登出视图示例：登出操作一般基于Session认证，这时候DRF已经默认开启CSRF防护，加这个装饰器其实是冗余的，但也不会有问题——相当于再次明确开启防护，功能上没区别。

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