如何正确使用DRF Serializer的.save()、.create()和.to_internal_value()方法？

这三个方法是DRF序列化器写入流程里的串行执行环节，职责完全分离，不存在功能重合，最佳实践就是严格守住各自的职责边界：

1. .to_internal_value()：输入数据的转换与基础校验 #

作为写入流程的第一关，它负责把前端传入的原始数据（比如JSON字符串、数字）转换成Django模型能接受的Python内部类型，同时做通用格式验证。

• 最佳实践：
  • 只做数据类型转换和非业务逻辑的格式校验，比如把字符串转成日期对象、把ID字符串转成外键实例、校验邮箱格式等。
  • 不处理业务逻辑（比如权限判断、关联数据的业务规则），也不直接操作数据库。
  • 示例：

    def to_internal_value(self, data):
        # 将前端字符串日期转为datetime对象
        data['expire_date'] = datetime.strptime(data['expire_date'], '%Y-%m-%d')
        # 将用户ID转为User实例
        data['owner'] = User.objects.get(id=data['owner_id'])
        # 调用父类完成默认验证逻辑
        return super().to_internal_value(data)
    

2. .create()：新实例的初始化与业务逻辑处理 #

它是创建新实例的核心逻辑，接收.to_internal_value()处理后的验证数据，负责初始化模型实例、处理业务关联规则，最后返回创建好的实例（无需自行调用save()，框架会处理持久化）。

• 最佳实践：
  • 只负责新实例的创建逻辑，比如设置实例默认值、关联多对多关系、执行创建时的业务动作（比如创建订单时扣减库存）。
  • 不重复做数据转换或格式校验，这类工作交给.to_internal_value()。
  • 示例：

    def create(self, validated_data):
        # 拆分验证数据中的多对多字段
        tags_data = validated_data.pop('tags')
        # 创建主实例
        article = Article.objects.create(**validated_data)
        # 关联多对多标签
        article.tags.add(*tags_data)
        # 执行创建时的业务逻辑：发送通知
        send_article_notification(article)
        return article
    

3. .save()：持久化的统一触发入口 #

这是对外暴露的持久化接口，会自动调用.to_internal_value()完成数据转换验证，然后根据操作类型（创建/更新）分别调用.create()或.update()，最终完成实例的数据库持久化。

• 最佳实践：
  • 业务代码（比如视图中）仅调用.save()，不要直接调用.to_internal_value()或.create()/.update()。
  • 如需传递上下文数据（比如当前登录用户），可通过.save(**kwargs)传入，在.create()/.update()中接收使用。
  • 示例（视图中）：

    def post(self, request):
        serializer = ArticleSerializer(data=request.data)
        serializer.is_valid(raise_exception=True)
        # 传入当前用户作为创建上下文
        serializer.save(owner=request.user)
        return Response(serializer.data, status=status.HTTP_201_CREATED)
    

总结 #

• .to_internal_value()：聚焦「数据格式转换、基础校验」，属于纯数据处理层
• .create()：聚焦「实例初始化、业务逻辑实现」，属于业务逻辑层
• .save()：聚焦「统一触发流程」，是对外调用的标准入口

严格遵循这个分工，能让序列化器代码更清晰、易维护，完全契合DRF的设计初衷。

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