Serializer构造时：序列化用instance，反序列化用data；混用会导致is_valid()报错或静默失效；many=True要求instance为QuerySet/list、data为dict列表；to_representation()中需防N+1和AttributeError；validated_data仅在data模式校验后存在，不深拷贝；复杂逻辑优先BaseSerializer。
Serializer 构造时传 instance 还是 data？
取决于你要干啥：序列化用 instance，反序列化用 data。两者不能混用，否则 is_valid() 会报错或静默失效。
常见错误现象：传了 instance 却调 is_valid() —— 它永远返回 True，因为没做校验；传了 data 却直接读 .data —— 报 AttributeError: 'Serializer' object has no attribute 'data'，因为没调 is_valid() 或校验失败。
- 序列化场景（输出数据）：
serializer = SnippetSerializer(instance=snippet)→ 然后serializer.data - 反序列化场景（接收并校验输入）：
serializer = SnippetSerializer(data=request.data)→ 必须先serializer.is_valid(raise_exception=True)→ 再取serializer.validated_data -
many=True只影响instance或data的类型：前者必须是 QuerySet 或 list，后者必须是 list of dict
to_representation() 里访问 model 字段要小心
重写 to_representation() 是控制输出结构最直接的方式，但容易踩坑：model 实例可能带 lazy relation（比如未 prefetch 的外键），导致 N+1 查询；字段名写错或用了不存在的属性，会静默返回 None 或抛 AttributeError。
使用场景：需要定制字段名、拼接字段、嵌套结构扁平化、或动态加字段（如当前用户权限标识）。
- 避免 N+1：确保外键字段已
select_related()或prefetch_related()，不要在to_representation()里触发新查询 - 安全取值：用
getattr(instance, 'field_name', None)替代直接点取，尤其对可为空或延迟加载字段 - 别在
to_representation()里调save()或修改 instance —— 它只负责读，不负责写
反序列化时 validated_data 和 data 的区别
serializer.data 是序列化后的结果（dict），只在 instance 模式下可用；serializer.validated_data 是反序列化校验通过后的干净数据（dict），只在 data 模式且 is_valid() 为 True 后存在。
性能影响：DRF 不会在 validated_data 上做深拷贝，所以它和原始输入共享引用——如果你在 create() 或 update() 中修改了 validated_data，会影响后续逻辑。
- 校验失败时，
serializer.errors是 dict，validated_data未定义 -
required=False字段若未传，不会出现在validated_data中，不是None - 自定义字段（如
serializers.SerializerMethodField）不出现在validated_data里，只用于序列化输出
BaseSerializer 和 ModelSerializer 的选择边界
别为了“省几行代码”盲目用 ModelSerializer。它自动推导字段和验证规则，但灵活性差、调试难、容易暴露不该暴露的字段。
复杂对象转换往往涉及非模型字段、跨表计算、条件逻辑、或第三方服务数据拼接 —— 这些都更适合 BaseSerializer 手动控制。
- 用
ModelSerializer：CRUD 标准接口、字段与模型严格一致、无业务逻辑掺杂 - 用
BaseSerializer：需要字段重命名、组合多个模型、嵌入非 DB 数据（如缓存值、API 调用结果）、或字段逻辑依赖上下文（如context['request'].user） -
BaseSerializer不自动提供create()/update()，必须自己写，但这也意味着你能完全掌控保存逻辑
context 的传递时机——它必须在构造 serializer 时传入，之后无法修改；而很多开发者把它当成万能兜底参数，却忘了在 view 或 APIView 的 get_serializer_context() 里显式注入 request、user 等关键信息。 
