Django REST Framework移动端应用多版本代码实现优化方案咨询

你现在用if-else判断版本的方式虽然能跑通，但随着版本迭代，代码会越来越臃肿，维护成本也会直线上升。DRF本身提供了几种更优雅的版本管理方案，我给你整理几个常用的：

1. 用DRF内置版本控制类+方法映射替代if-else #

DRF自带了多种版本控制机制（比如URL路径、请求头、查询参数），先配置全局版本规则，再用字典映射把不同版本的逻辑拆成独立方法，代码结构会清晰很多。

第一步：配置全局版本控制 #

在settings.py里添加版本控制的全局配置：

REST_FRAMEWORK = {
    # 这里选URL路径版本控制，也可以换成请求头/查询参数模式
    'DEFAULT_VERSIONING_CLASS': 'rest_framework.versioning.URLPathVersioning',
    'DEFAULT_VERSION': '1.0',
    'ALLOWED_VERSIONS': ['1.0', '2.0', '3.0', '4.0'],
    'VERSION_PARAM': 'version'
}

如果想用请求头传版本，把DEFAULT_VERSIONING_CLASS换成rest_framework.versioning.AcceptHeaderVersioning，客户端只需要在请求头里传Accept: application/json; version=1.0就行。

第二步：在视图里用方法映射处理版本逻辑 #

配置好后，视图里可以通过request.version直接拿到当前版本，然后用字典把版本和对应的处理方法绑定：

from rest_framework.views import APIView
from rest_framework.response import Response

class MyAPIView(APIView):
    def get(self, request):
        # 版本和处理方法的映射，相同逻辑的版本可以复用同一个方法
        version_handlers = {
            '1.0': self.handle_v1_v2,
            '2.0': self.handle_v1_v2,
            '3.0': self.handle_v3_v4,
            '4.0': self.handle_v3_v4
        }
        # 拿到对应版本的处理方法，默认用兜底逻辑
        handler = version_handlers.get(request.version, self.handle_default)
        return handler(request)
    
    def handle_v1_v2(self, request):
        # 1.0和2.0版本的专属逻辑
        return Response({'message': 'Response for v1.0/v2.0'})
    
    def handle_v3_v4(self, request):
        # 3.0和4.0版本的专属逻辑
        return Response({'message': 'Response for v3.0/v4.0'})
    
    def handle_default(self, request):
        # 未匹配到版本的兜底逻辑
        return Response({'message': 'Default version response'})

这种方式把不同版本的逻辑完全解耦，后续加新版本只需要在字典里加映射、写对应的方法就行，比堆if-else清爽太多。

2. 拆分视图类，按版本独立维护 #

如果不同版本的逻辑差异极大（比如序列化字段、业务流程完全不同），直接把视图拆成版本专属的类会更干净。

第一步：创建版本专属的序列化器和视图 #

from rest_framework import serializers
from .models import MyModel

# 不同版本的序列化器
class V1Serializer(serializers.ModelSerializer):
    class Meta:
        model = MyModel
        fields = ['id', 'name', 'create_time']

class V2Serializer(serializers.ModelSerializer):
    class Meta:
        model = MyModel
        fields = ['id', 'name', 'create_time', 'update_time', 'status']

# 不同版本的视图
class V1MyAPIView(APIView):
    def get(self, request):
        queryset = MyModel.objects.all()
        serializer = V1Serializer(queryset, many=True)
        return Response(serializer.data)

class V2MyAPIView(APIView):
    def get(self, request):
        queryset = MyModel.objects.filter(status=True)  # V2专属过滤逻辑
        serializer = V2Serializer(queryset, many=True)
        return Response(serializer.data)

第二步：配置URL路由分发 #

直接在urls里把不同版本的路径指向对应的视图：

from django.urls import path
from .views import V1MyAPIView, V2MyAPIView

urlpatterns = [
    path('api/v1/my-resource/', V1MyAPIView.as_view()),
    path('api/v2/my-resource/', V1MyAPIView.as_view()),  # 复用V1逻辑
    path('api/v3/my-resource/', V2MyAPIView.as_view()),
    path('api/v4/my-resource/', V2MyAPIView.as_view()),  # 复用V2逻辑
]

这种方式适合版本间差异大的场景，每个版本的视图完全独立，互不干扰，后期维护和排查问题都更方便。

3. 用装饰器封装简单版本判断 #

如果只是个别接口需要版本区分，逻辑又比较简单，可以用装饰器封装版本判断逻辑：

def version_route(versions, handler):
    def decorator(view_func):
        def wrapped(request, *args, **kwargs):
            if request.version in versions:
                return handler(request, *args, **kwargs)
            return view_func(request, *args, **kwargs)
        return wrapped
    return decorator

class MyAPIView(APIView):
    @version_route(['1.0', '2.0'], lambda req: Response({'msg': 'v1 response'}))
    @version_route(['3.0', '4.0'], lambda req: Response({'msg': 'v2 response'}))
    def get(self, request):
        # 默认逻辑
        return Response({'msg': 'default response'})

不过这种方式只适合简单场景，复杂逻辑还是推荐前两种方案。

总体来说，优先推荐用DRF内置版本控制+方法映射，或者拆分视图类的方式，这两种都比堆if-else更易扩展和维护。

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