一、原生 Django 开发 API 的局限性
虽然 Django 可以通过 JsonResponse 和视图函数手动构建 API，但存在以下问题：
- 手动序列化与反序列化
需要手动将模型实例转换为 JSON，处理复杂数据类型（如嵌套关系）时代码冗长且易错。
示例：原生 Django 返回 JSON 数据
python
from django.http import JsonResponse
from .models import Book
def book_list(request):
books = Book.objects.all()
data = [{"title": book.title, "author": book.author} for book in books]
return JsonResponse(data, safe=False)
缺点：无法自动处理模型关联、验证输入数据，且代码重复率高。- 复杂的请求处理
需要手动解析请求体中的 JSON 数据，并处理不同 HTTP 方法（GET/POST/PUT/DELETE）。
示例：原生处理 POST 请求
python
import json
from django.views.decorators.csrf import csrf_exempt
@csrf_exempt
def create_book(request):
if request.method == "POST":
try:
data = json.loads(request.body)
book = Book.objects.create(**data)
return JsonResponse({"id": book.id}, status=201)
except Exception as e:
return JsonResponse({"error": str(e)}, status=400)缺点：缺少自动数据验证、错误处理逻辑复杂。
-
缺乏标准化功能
需自行实现以下功能：
认证与权限（如 Token、JWT、OAuth）。 分页（处理大数据集的分页逻辑）。 限流（防止 API 被滥用）。 文档生成（手动维护 API 文档）。 -
维护成本高
随着项目规模扩大，手动编写的 API 代码难以统一管理，容易产生冗余和潜在安全漏洞。
二 、DRF 的核心优势
DRF 针对上述问题提供了系统化解决方案，显著提升开发效率与代码质量。
- 序列化与反序列化自动化
序列化器（Serializer）：
自动将模型实例转换为 JSON，支持复杂关系（如一对多、多对多）。
内置数据验证逻辑，确保输入数据符合预期格式。
示例：DRF 序列化器
python
from rest_framework import serializers
class BookSerializer(serializers.ModelSerializer):
class Meta:
model = Book
fields = "__all__"- 视图抽象化
视图集（ViewSets） 和 通用视图（Generic Views）：
通过 ModelViewSet 自动生成 CRUD 接口，减少 70% 的重复代码。
示例：DRF 视图
python
from rest_framework import viewsets
class BookViewSet(viewsets.ModelViewSet):
queryset = Book.objects.all()
serializer_class = BookSerializer- 开箱即用的高级功能
| 功能 | 原生 Django 实现难度 | DRF 实现方式 |
|---|---|---|
| 认证 | 高（需手动集成） | 一行配置（authentication_classes） |
| 权限控制 | 高 | 一行配置（permission_classes） |
| 分页 | 中 | 内置分页类（PageNumberPagination） |
| 限流 | 高 | 配置 throttle_classes |
| API 文档 | 高（需第三方库） | 自动生成（swagger、redoc） |
-
标准化与安全性
认证方案：支持 Token、Session、JWT、OAuth2 等。
权限粒度：基于角色（IsAdminUser）、对象级别（DjangoObjectPermissions）的权限控制。
安全防护：自动处理 CSRF、XSS 等常见安全问题。
-
生态系统与社区支持
扩展插件：支持 django-filter（过滤）、drf-yasg（文档）、djangorestframework-simplejwt（JWT 认证）等。
活跃社区：GitHub 15k+ Stars，Stack Overflow 上超 10 万相关问题，解决问题更高效。
三、典型场景对比
场景：开发一个支持过滤、分页和权限控制的图书 API
原生 Django：
python
# 需要手动实现过滤、分页、权限逻辑，代码量约 100+ 行
from django.core.paginator import Paginator
def book_list(request):
# 过滤
author = request.GET.get("author")
books = Book.objects.filter(author=author) if author else Book.objects.all()
# 分页
paginator = Paginator(books, 10)
page = paginator.get_page(request.GET.get("page"))
# 手动序列化
data = [{"title": book.title} for book in page]
return JsonResponse({"results": data, "count": paginator.count})DRF：
python
#通过配置实现相同功能，代码量 10 行
from rest_framework import viewsets, filters
class BookViewSet(viewsets.ModelViewSet):
queryset = Book.objects.all()
serializer_class = BookSerializer
filter_backends = [filters.SearchFilter]
search_fields = ["author"]
pagination_class = PageNumberPagination
permission_classes = [IsAuthenticated]四、何时选择原生 Django？
尽管 DRF 优势明显，但在以下场景可能更适合原生 Django：
1.极简 API：仅需返回少量简单数据。
2.性能敏感：DRF 的抽象层可能带来轻微性能开销（通常可忽略）。
3.避免依赖：项目要求最小化第三方库。
五、总结
| 维度 | 原生 Django | DRF |
|---|---|---|
| 开发效率 | 低（需手动实现所有功能） | 高（开箱即用，代码量减少 50%+） |
| 功能完整性 | 基础 | 完整（认证、权限、分页、限流等） |
| 维护成本 | 高（代码冗余，难扩展） | 低（标准化配置，易于迭代） |
| 安全性 | 需自行处理 | 内置防护机制 |
| 适用场景 | 简单接口或小型项目 | 中大型项目、需标准化 API 的企业应用 |
结论：DRF 是 Django 生态中构建 API 的"工业级"工具，其设计哲学与 Django 一致（DRY原则），适合绝大多数需要高效、安全、可维护的 API 开发场景。原生 Django 仅适用于极简需求或对性能/依赖有严格限制的特殊情况。