在 DRF 中，create() 方法必须返回模型实例，否则会触发 AssertionError；若需抛出如 PermissionDenied 等业务异常，应在序列化器内捕获并原样重抛，确保异常被 DRF 异常处理机制捕获并转换为标准 HTTP 响应。
在 drf 中，`create()` 方法必须返回模型实例，否则会触发 `assertionerror`；若需抛出如 `permissiondenied` 等业务异常，应在序列化器内捕获并原样重抛，确保异常被 drf 异常处理机制捕获并转换为标准 http 响应。
在 Django REST Framework 中，ModelSerializer.create() 方法的设计契约非常明确：必须返回一个已创建的对象实例。一旦该方法因未处理的异常而提前退出（例如 ConsultationService.create_consultation() 抛出 PermissionDenied），Python 函数默认返回 None，DRF 内部校验逻辑便会抛出 AssertionError: create() did not return an object instance.——这并非业务错误，而是违反了框架契约的实现错误。
正确的做法是：将业务异常的捕获与传播逻辑前置到序列化器的 create() 方法中，而非依赖视图层兜底。这样既符合职责分离原则，又能确保异常类型不被掩盖、状态码准确（如 PermissionDenied → HTTP 403）、响应结构统一（遵循 DRF 的 ExceptionHandler 标准格式）。
以下是推荐实现：
使用 Infinimo AI 设计制作手持产品短视频：Avatar 首帧合成、AI 脚本、图转视频提交与轮询。适用于可购物短视频、Avatar 主导的产品演示和商品 listing 宣传视频。
from rest_framework import serializers, exceptions
from .services import ConsultationService
class ConsultationSerializer(serializers.ModelSerializer):
class Meta:
model = Consultation
fields = '__all__'
def create(self, validated_data):
# 提前提取并移除非字段数据（如 customer）
customer = validated_data.pop('customer', None)
try:
# 调用业务服务，可能抛出 PermissionDenied 等 DRF 标准异常
consultation = ConsultationService.create_consultation(customer, validated_data)
return consultation # ✅ 必须返回实例
except exceptions.PermissionDenied:
# 原样重抛，确保被 DRF 全局异常处理器捕获
raise
except exceptions.ValidationError:
# 同理，保留原始 ValidationError（含字段级错误）
raise
except Exception as e:
# 对非 DRF 异常做安全降级：转为通用 ValidationError（含日志建议）
raise serializers.ValidationError(f"Consultation creation failed: {str(e)}")⚠️ 注意事项：
-
切勿在
create()中静默吞掉异常或返回None，这将直接触发 AssertionError； -
避免在 ViewSet 的
perform_create()中二次包装AssertionError（如题中except AssertionError方案），它掩盖了真实错误根源，且PermissionDenied被错误地降级为 500 或 400； - 若
ConsultationService.create_consultation()抛出的是自定义异常，需显式转换为 DRF 兼容异常（如ValidationError、PermissionDenied、NotFound），否则将触发未处理异常（HTTP 500）； - 所有异常最终由 DRF 的
exception_handler统一处理，生成符合{"detail": "..."}或字段级{"field_name": ["error"]}结构的 JSON 响应，并附带对应 HTTP 状态码。
通过将异常处理逻辑收束至序列化器 create() 方法，你不仅修复了 AssertionError，更构建了清晰、可测试、符合 DRF 约定的错误传播链路。
