Django视图中使用Class类视图还是def函数视图更好？适用场景有哪些？

首先明确：二者没有绝对的优劣，只存在场景适配的差异，实际项目中绝大多数团队都是二者混用，不需要强行统一选型。

核心差异 #

• 函数视图（FBV）：是最基础的视图实现形式，本质是普通Python函数，接收HttpRequest对象作为入参，返回HttpResponse对象，逻辑完全线性展开，没有额外的封装层。
• 类视图（CBV）：基于Python类封装实现，Django默认提供了HTTP请求方法自动分发、通用CRUD逻辑封装、Mixin扩展等能力，适合通过继承复用代码。

各自适用场景 #

优先选择FBV的场景 #

• 视图逻辑高度定制、无复用需求：比如编写单次使用的webhook回调接口、临时活动页接口，逻辑行数在20行以内的场景，FBV写起来直接利落，不需要继承类、重写方法，代码可读性更高。
• 团队成员对Django CBV的继承链不熟悉：FBV的逻辑完全在当前函数内，不需要跳转父类查找逻辑入口，维护和调试成本更低，更适合新人占比高的团队。
• 处理多环节复杂联动逻辑：比如支付回调、订单状态流转这类涉及验签、状态修改、跨服务调用、消息推送的长流程逻辑，线性写在FBV中比拆分到CBV的多个方法里更容易梳理流程，调试时不需要在多层继承关系里来回跳转。

优先选择CBV的场景 #

• 需要复用通用视图逻辑：比如后台管理系统中多个模型需要实现增删改查功能，直接继承Django内置的ListView、CreateView、UpdateView、DeleteView等通用类视图，仅需要指定model、template_name、form_class等少量属性即可完成完整CRUD模块开发，代码量比FBV减少60%以上。
• 同一视图需要支持多种HTTP方法：比如RESTful接口需要同时支持GET查询、POST新增、PUT修改、DELETE删除，用CBV直接定义get()、post()、put()、delete()方法即可，不需要在FBV中手写大量if request.method == 'XXX'的判断分支，结构更清晰。
• 需要叠加多个通用扩展能力：比如给视图加登录校验、权限控制、缓存等能力时，直接继承LoginRequiredMixin、PermissionRequiredMixin等内置Mixin即可，不需要给每个FBV重复加装饰器，多个能力叠加时代码更整洁。

切换选型的时机 #

不需要死守某一种实现方式，出现以下情况时可以考虑切换：

• 写FBV时发现同一段逻辑已经在3个及以上视图中重复出现：比如每个视图都要做相同的权限校验、参数预处理、分页封装，换成CBV+公共父类/Mixin可以大幅降低重复代码，后续修改仅需要调整一次公共逻辑即可。
• 写CBV时需要重写超过3个父类方法，甚至要修改父类核心分发逻辑：比如本来想复用通用ListView，结果需要重写get_queryset、get_context_data、post、render_to_response等多个方法，还要修改父类的默认参数，这时候换成FBV反而更直接，不需要花精力兼容类继承链的原有逻辑，代码可读性反而更高。
• 核心高并发接口出现性能瓶颈：FBV的调用链比CBV更短，性能略高（常规场景下差异可忽略），如果压测时发现CBV的额外开销成为性能瓶颈，可以换成FBV实现。

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